#asterisk filter

[voipfaqs-blog]

Asterisk Filter Application

The FILTER() dialplan function is used to filter strings by only allowing characters that you have specified. This is a perfect candidate for controlling which characters you want to pass to the Dial() application, or any other application which will contain dynamic information passed to Asterisk from an external source. Lets take a look at how we can use FILTER() to control what data we allow. Using our previous example to accept any string length of 2 or more characters, starting with a number of zero through nine, we can use FILTER() to limit what we will accept to just numbers. Our example would then change to something like: [incoming] exten => _X.,1,Verbose(2,Incoming call to extension ${EXTEN}) exten => _X.,n,Dial(SIP/${FILTER(0-9,${EXTEN})}) exten => _X.,n,Hangup() Note how we've wrapped the ${EXTEN} channel variable with the FILTER() function which will then only pass back characters that fit into the numerical range that we've defined. Alternatively, if we didn't want to utilize the FILTER() function within the Dial() application directly, we could save the value to a channel variable, which has a side effect of being usable in other locations of your dialplan if necessary, and to handle error checking in a separate location. [incoming] exten => _X.,1,Verbose(2,Incoming call to extension ${EXTEN}) exten => _X.,n,Set(SAFE_EXTEN=${FILTER(0-9,${EXTEN})}) exten => _X.,n,Dial(SIP/${SAFE_EXTEN}) exten => _X.,n,Hangup() Now we can use the ${SAFE_EXTEN} channel variable anywhere throughout the rest of our dialplan, knowing we've already filtered it. We could also perform an error check to verify that what we've received in ${EXTEN} also matches the data passed back by FILTER(), and to fail the call if things do not match. [incoming] exten => _X.,1,Verbose(2,Incoming call to extension ${EXTEN}) exten => _X.,n,Set(SAFE_EXTEN=${FILTER(0-9,${EXTEN})}) exten => _X.,n,GotoIf($[${EXTEN} != ${SAFE_EXTEN}]?error,1) exten => _X.,n,Dial(SIP/${SAFE_EXTEN}) exten => _X.,n,Hangup() exten => error,1,Verbose(2,Values of EXTEN and SAFE_EXTEN did not match.) exten => error,n,Verbose(2,EXTEN: "${EXTEN}" -- SAFE_EXTEN: "${SAFE_EXTEN}") exten => error,n,Playback(silence/1&invalid) exten => error,n,Hangup() Another example would be using FILTER() to control the characters we accept when we're expecting to get a SIP URI for dialing. [incoming] exten => _[0-9a-zA-Z].,1,Verbose(2,Incoming call to extension ${EXTEN}) exten => _[0-9a-zA-Z].,n,Dial(SIP/${FILTER(.@0-9a-zA-Z,${EXTEN}) exten => _[0-9a-zA-Z].,n,Hangup() Of course the FILTER() function doesn't check the formatting of the incoming request. There is also the REGEX() dialplan function which can be used to determine if the string passed to it matches the regular expression you've created, and to take proper action on whether it matches or not. The creation of regular expressions is left as an exercise for the reader. More information about the FILTER() and REGEX() dialplan functions can be found by typing "core show function FILTER" and "core show function REGEX" from your Asterisk console.

[voipfaqs-blog]

Strict Pattern Matching In Asterisk

One of the simpler ways to mitigate the problem of having provided someone with a method to place calls out of your ITSP in a place where you didn't expect to allow it is with a strict pattern matching that does not utilize the period (.) or bang (!) characters to match on one-or-more characters or zero-or-more characters (respectively). To give an example that only accepts three digit extensions, we could use the following pattern match: exten => _XXX,n,Dial(SIP/${EXTEN}) In this way, we have minimized our impact because we're not allowing anything other than the numbers zero through nine. But in some cases we really do need to handle variable pattern matches, such as when dialing international numbers or when we want to handle something like a SIP URI. In this case, we'll need to utilize the FILTER() dialplan function.

[voipfaqs-blog]

Filtering Data In Asterisk DialPlan

In the Asterisk dialplan, several channel variables contain data potentially supplied by outside sources. This could lead to a potential security concern where those outside sources may send cleverly crafted strings of data which could be utilized, e.g. to place calls to unexpected locations. An example of this can be found in the use of pattern matching and the ${EXTEN} channel variable. Note that ${EXTEN} is not the only system created channel variable, so it is important to be aware of where the data you're using is coming from. For example, this common dialplan takes 2 or more characters of data, starting with a number 0-9, and then accepts any additional information supplied by the request. [NOTE: We use SIP in this example, but is not limited to SIP only; protocols such as Jabber/XMPP or IAX2 are also susceptible to the same sort of injection problem.] [incoming] exten => _X.,1,Verbose(2,Incoming call to extension ${EXTEN}) exten => _X.,n,Dial(SIP/${EXTEN}) exten => _X.,n,Hangup() This dialplan may be utilized to accept calls to extensions, which then dial a numbered device name configured in one of the channel configuration files (such as sip.conf, iax.conf, etc...) (see the section Proper Device Naming for more information on why this approach is flawed). The example we've given above looks harmless enough until you take into consideration that several channel technologies accept characters that could be utilized in a clever attack. For example, instead of just sending a request to dial extension 500 (which in our example above would create the string SIP/500 and is then used by the Dial() application to place a call), someone could potentially send a string like "500&SIP/itsp/14165551212". The string "500&SIP/itsp/14165551212" would then be contained within the ${EXTEN} channel variable, which is then utilized by the Dial() application in our example, thereby giving you the dialplan line of: exten => _X.,n,Dial(SIP/500&SIP/itsp/14165551212)

Our example above has now provided someone with a method to place calls out of your ITSP in a place where you didn't expect to allow it. There are a couple of ways in which you can mitigate this impact:

using strict pattern matching, or

using the FILTER() dialplan function.