Dialplan Security

Asterisk Asterisk Support
1

I have Asterisk 11.12.0 with a Digium 4 port analog card (1AA00F). Port 1 is FXO and ports 2-4 are FXS. No SIP protocol. I have been researching Asterisk security and most of what I have found refers to SIP protocol vulnerability and does not mention Dahdi/PSTN. One of the basic security rules that does seem to apply is to keep inbound/call processing and outbound routing in separate contexts. My dial plan does have separate contexts for incoming, call processing, outgoing calls, and internal calls. My concern is in the section of my dialplan below. Outbound dialing will not work unless I have the include line in the localsets context. This seems to defeat the separation of the 2 contexts. My questions are:

  1. Is what I have in my dialplan below a security risk?
  2. If so, should I work at moving the pattern matching currently in the outgoing context to the localsets context with Gotos to a single line to dial out in the outgoing context?

If you have other recommendations I would appreciate them.

[globals]
OUT=DAHDI/1

[outgoing]
exten => _NXXNXXXXXX,1,Dial(${OUT}/${EXTEN})
exten => _NXXXXXX,1,Dial(${OUT}/${EXTEN})
exten => _1NXXNXXXXXX,1,Dial(${OUT}/${EXTEN})
exten => _911,1,Dial(${OUT}/${EXTEN})
exten => _411,1,Dial(${OUT}/${EXTEN})
exten => _*99,1,Dial(${OUT}/${EXTEN})

[localsets]
include => outgoing
exten => 101,1,Dial(DAHDI/2)
exten => 102,1,Dial(DAHDI/3)
exten => 103,1,Dial(DAHDI/4)

2

Assuming that DAHDI will start reading digits, from the caller, you have this the wrong way round. 101 to 103, should be in a context of their own, the only one to which outside callers have access. Inside caller should then have access to context that includes that context and one with all the external numbers (you could also have the external numbers inline in that context).

Because DAHDI dialing is always overlap dialing, I don’t think that your first two lines are correct, as the short one could match a number that should use the long one. I’m guessing the built in logic uses a timeout, but you really only want to rely on that timeout when you can’t predict the number length from the digits already dialed.

3

To David55:
Thank you for the response. I did forget to mention that this dial plan has been running successfully for several years. Based on your comments I did some more research on Asterisk pattern matching and have changed the order of pattern matching statements to hopefully make the dial plan more efficient. I also altered the dial plan to create a single statement in the outgoing context that routes the external calls to the provider and isolates the dial out from the rest of the dial plan. I have tested this in a small test environment, but it will be a while before I can test it in the live environment. Below is the section of the dial plan that I changed. If you see any issues please let me know.

[globals]
OUT=DAHDI/1

[localsets]
exten => _911,1,NoOp(${EXTEN})
same => n,Goto(outgoing,${EXTEN},1)
exten => _411,1,NoOp(${EXTEN})
same => n,Goto(outgoing,${EXTEN},1)
exten => _*99,1,NoOp(${EXTEN})
same => n,Goto(outgoing,${EXTEN},1)
exten => _NXXNXXXXXX,1,NoOp(${EXTEN})
same => n,Goto(outgoing,${EXTEN},1)
exten => _NXXXXXX,1,NoOp(${EXTEN})
same => n,Goto(outgoing,${EXTEN},1)
exten => _1NXXNXXXXXX,1,NoOp(${EXTEN})
same => n,Goto(outgoing,${EXTEN},1)
exten => 101,1,Dial(DAHDI/2)
exten => 102,1,Dial(DAHDI/3)
exten => 103,1,Dial(DAHDI/4)

[outgoing]
exten => _X.,1,Dial(${OUT}/${EXTEN})
same => n,Hangup()

4

The order doesn’t affect the way the match is done.