[cisco-voip] Call Manager Denial of Service and Gateway Call Spike

Mon Oct 17 14:06:30 EDT 2011

The document says it's for H.323, but if it's using the total call count it
may work with MGCP as well.  'show call active voice brief' still shows MGCP
calls in the call history/information.  It's a global command not on a dial
peer so it's all going through the same voice stack.

In terms of the numbers to use it's a matter of figuring out the CPS.  You
could figure that out from the BHCA.  It will probably be a number between 1
and 30 CPS depending on how busy your environment is.  Most ISRs can handle
between 1-10ish and the AS5x00 and larger boxes ( 3900s) handle much more
than that.

If you say your CPS is 4, if the maximum interval is 250ms, then if your
calls are 1 per 250ms.  So if you say you should never receive 5x that in an
interval you would say no more than 5 calls per 250 ms.  You may want to
account for things like if you send out a large distribution voicemail many
people may check voicemail at the same time, etc.

Otherwise you could do something a little bit dirtier, like create a policer
on the signaling traffic.  It's really dirty, but it may be less of an issue
than bringing down a subscriber.

-nick

On Fri, Oct 14, 2011 at 1:17 PM, Wes Sisk <wsisk at cisco.com> wrote:

> ASA can rate limit based on protocol and message type. We've recommended
> and used this in deployments before where a malicious device DoS's the
> system:
>
> http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/inspect_voicevideo.html#wp1514402
>
> think along the lines of rate limiting h323 setup messages.  You could even
> do it by TCP session rate as every call is a new TCP session.
>
> The same works for analog MGCP.  This also works for SCCP (this is where
> I've seen the most usage).
>
>
> For digital MGCP (PRI and CAS mgcp backhaul) I am not aware of a similar
> ASA inspection feature.  Perhaps IOS can police the rate at the endpoint?
>  Nick or others may chime in with options.
>
>
>
> One oddity does stand out.  I've pushed ccm above 43 calls per second
> before without entering code yellow. At 43 cps the ICTCallThrottlingStart
> alarm fires and CM begins limiting calls to/from this specific h.323 device.
>
>
> A "well tuned system" is likely to hit that rate limiter on a malicious
> h.323 gateway prior to entering code yellow.  I'm still stumped on how to
> handle this for MGCP Backhaul.
>
>
> Regards,
> Wes
>
> On Oct 14, 2011, at 12:56 PM, Casper, Steven wrote:
>
> We recently had an incident where a power dialer inadvertently was
> programmed to dial thousands of our numbers. The rate of dialing was such
> that two of our subscribers went into a code yellow condition so in effect
> created a Denial of Service condition. Both of these servers (7845H2) have a
> lot of MGCP and H323 PRIs associated with them. I am looking for ways to
> prevent this in the future. I see there is a call spike command available on
> gateways but I am not sure what thresholds would be used. Any ideas…..What
> would be a good threshold to set to prevent a denial of service condition
> but still support  normal heavy inbound calling?****
> ** **
> *call spike*
> To configure the limit on the number of incoming calls received in a short
> period of time (a call spike), use the *call spike* command in global or
> dial peer voice configuration mode. To disable this command, use the* no* form
> of this command.****
> *call spike* *call*-*number* [*steps* *number*-*of*-*steps* *size* *
> milliseconds*]****
> *no* *call spike*****
> Dial Peer Voice Configuration Mode****
> *call spike* *threshold *[*steps* *number-of-steps* *size* *milliseconds*]
> ****
> *Syntax Description*
>  *call*-*number*****
>  Incoming call count for the spiking threshold. Range is 1 to 2147483647.*
> ***
>  *steps**number*-*of*-*steps*****
>  (Optional) Specifies the number of steps for the spiking sliding window.
> Range is from 3 to 10. The default is 5.steps for the spiking sliding
> window.****
>  *size**milliseconds*****
>  (Optional) Specifies step size in milliseconds. Range is from 100 to 250.
> The default is 200.****
>  *threshold*****
>  Threshold for the incoming call count for spiking. Range is 1 to
> 2147483647.****
> ** **
> *Usage Guidelines*
> A call spike occurs when a large number of incoming calls arrive from the
> Public Switched Telephone Network (PSTN) in a short period of time (for
> example, 100 incoming calls in 10 milliseconds). Setting this command allows
> you to control the number of call requests that can be received in a
> configured time period. The sliding window buffers the number of calls that
> get through. The counter resets according to the specified step size.****
> The period of the sliding window is calculated by multiplying the number of
> steps by the size. If an incoming call exceeds the configured call number
> during the period of the sliding window the call is rejected.****
> If the *call spike* is configured at both the global and dial-peer levels,
> the dial-peer level takes precedence and the call spike is calculated. If
> the call spike threshold is exceeded the call gets rejected, and the call
> spike calculation is done at the global level.****
> ** **
> ** **
> ** **
> ************************************
> This email may contain privileged and/or confidential information that is
> intended solely for the use of the addressee.  If you are not the intended
> recipient or entity, you are strictly prohibited from disclosing, copying,
> distributing or using any of the information contained in the transmission.
> If you received this communication in error, please contact the sender
> immediately and destroy the material in its entirety, whether electronic or
> hard copy.  This communication may contain nonpublic personal information
> about consumers subject to the restrictions of the Gramm-Leach-Bliley Act
> and the Sarbanes-Oxley Act.  You may not directly or indirectly reuse or
> disclose such information for any purpose other than to provide the services
> for which you are receiving the information.
> There are risks associated with the use of electronic transmission.  The
> sender of this information does not control the method of transmittal or
> service providers and assumes no duty or obligation for the security,
> receipt, or third party interception of this transmission.
> ************************************
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20111017/72f91d09/attachment.html>