Securing your Cisco CME Labs from Toll Fraud.
Hi again World!
I'm quite busy in the last weeks (and I expect to be so for a pair of months) but even so, as I was a victim of toll fraud while plying with my CCNA Voice labs, I though I had to get time anyhow to share my experience with others.
In fact, a quick search in Google using the words CISCO toll fraud yields a lot of results of cisco forums with people having suffered this. Also, there is quite CISCO official documentation about the matter.
Long history short: if you have buyed on eBay an old ISR router to play with CME in your home labs, and you connect it to your home PSTN connection, be advised that until IOS 15.0 (at that point CISCO reacted), any version of CME acts as a free SIP trunk, so, any rogue PBX can relay international calls using your connection!!!
Fortunately, only a few minutes of calls where placed, but this gave me an idea of how hostile Internet can be, with Asterisk servers aggressively scanning the internet looking to open SIP ports offering no authentication protection.
To be sincere, in fact, three facts have to occur simultaneously (and they did in my lab), so this problem is not easy to happen in real production scenarios (although according to CISCO forum a lot of times it did!!!!!).
First you have to have an old CME (mine is 7.1) so it comes with happy SIP trunking. Second, you have to have an FXO port (or wathever) to connect to PSTN. Third, you have to directly connect your ISR to the internet (for instant through a DSL interface).
Also, by reading at the CISCO forums I realized that yet another weak spot do exist: any PSTN connection not correctly configured is suitable to be used to forward calls... (guess to international destinations...)
So here are a set of steps to do in order to play with your CISCO toys at home relatively safe (is anything really safe?).
Turn your ISR into a firewall
CME makes the difference with my 1841 ISR, with CME, now the "who cares?" is no longer appliable...
So ACLs come to action, applying them on your WAN interface (in my case a Dialer0 DSL interface).
It is important, to not rely just on the tcp established firewalling technique, since this just applies for TCP traffic, being UDP not connection oriented, and also experienced members at the CISCO forum claim this technique being easy to defeat.
So, a full fledged ACL, blocking VoIP known ports (along with ssh, telnet and so on) has to be tailored... In case of need of VoIP traffic to the outside, then exceptions should be added to the default block ACL.
Here's an example on how did the mines looked like... First the most important one, inbound:
ip access-list extended DSL-INBOUND
deny tcp any any eq 22 log
deny tcp any any eq 23 log
deny tcp any any eq 80
deny tcp any any eq 443
deny tcp any any range 1718 1720
deny tcp any range 1718 1720 any
deny tcp any any range 2000 2002
deny tcp any range 2000 2002 any
deny tcp any any range 5060 5100 log
deny tcp any range 5060 5100 any log
deny tcp any any range 11000 11999
deny tcp any range 11000 11900 any
deny udp any any range 1718 1720
deny udp any range 1718 1720 any
deny udp any any range 2000 2002
deny udp any range 2000 2002 any
deny udp any any range 5060 5100 log
deny udp any range 5060 5100 any log
permit tcp any any established
permit icmp any any
permit ahp any any
permit esp any any
permit udp any eq domain any
permit udp any eq ntp any
permit udp any any eq isakmp
permit udp any any eq non500-isakmp
deny ip any any
And here is the outbound direction ACL..
ip access-list extended DSL-OUTBOUND
deny tcp any eq 22 any
deny tcp any eq 23 any
deny tcp any eq 80 any
deny tcp any eq 443 any
deny tcp any any range 1718 1720
deny tcp any range 1718 1720 any
deny tcp any any range 2000 2002
deny tcp any range 2000 2002 any
deny tcp any any range 5060 5100 log
deny tcp any range 5060 5100 any log
deny tcp any any range 11000 11999
deny tcp any range 11000 11900 any
deny udp any any range 1718 1720
deny udp any range 1718 1720 any
deny udp any any range 2000 2002
deny udp any range 2000 2002 any
deny udp any any range 5060 5100 log
deny udp any range 5060 5100 any log
permit ip any any
Then applying the ACLs to the interface as usual:
interface Dialer0
ip access-group DSL-INBOUND in
ip access-group DSL-OUTBOUND out
Prevent FXO ports to give dial tone
By default, FXO ports do behave very happily in misconfigured environments. In the event of an incoming call on the PSTN line, if the CME does not know how to handle the call (no valid dial-peer), the FXO ports gives a dial tone, and allows the caller to enter digits (i.e an eventual extension), but this can be a potential security problem, since in certain situations it could be used to forward a call.
Most documents in CISCO CME toll fraud prevention literature point to set a "last resource" dial-peer for the FXO ports, coupled with the command direct-inward-dial.
That way, no matter what dos come from PSTN to our FXOs, the incoming call will be processed by CME (even if it could not have a way to handle it thereafter) and never will the FXO ports offer a dial tone to the other end-point.
Here's how it looks like:
dial-peer voice 1 pots
port 0/0/0
incoming called-number .
direct-inward-dial
!
dial-peer voice 2 pots
port 0/0/1
incoming called-number .
direct-inward-dial
Note the single dot, matching any digit, and the dial-inward-dial command.
Turn off unused services
One of the biggest improvements in security in IOS 15.x CME onwards is that. not only security control features have been added to services such as SIP or H323, but they are enabled by default!.
But on 12.4 CME 7.0, once you enable a service such as SIP, it behaves very happily, and you have to screen it by other means.
As pointed again at CISCO forums, by several people... "if you do not need or use it... just turn it off!!!"
So, if you're playing classic CCNA voice stuff, mostly with SCCP in the scene, you cant turn both SIP and H323 off, and sure then they're impossible to use!
Note the if you're playing with CUE, you will need SIP enabled to call your voice-mail or auto-attendant.
Here's how you just turn SIP and H323 off on your router:
voice service voip
h323
call service stop
sip
call service stop
Hardening telephony-service
There are a few tricks you can do to make your CME taste bitter to a rogue PBX. This tricks are not paramount, but do add additional layer of annoyance to the scene.
First, disable the incredibly happy feature of allow any unknown ephone (that would include a remote soft ephone) to register by default, found on CME.
Second, you can control call tranfers... by default, they are free of rules, but you can enforce transfer call patterns, so transfer of calls is just possible between your internal set of extensions.
Third, if you know approximately the time of your labs, consider setting up after hours policy, and set it to apply to any call, so outside your labs time span, your CME is essentially disabled to outgoing calls.
Here's an example on how the config script would like:
telephony-service
no auto-reg-ephone
!
transfer-pattern 1...
transfer-pattern 4...
transfer-pattern 8...
!
after-hours block pattern 1 0.T
after-hours day Sun 21:00 18:00
after-hours day Mon 21:00 18:00
after-hours day Tue 21:00 18:00
after-hours day Wed 21:00 18:00
after-hours day Thu 21:00 18:00
after-hours day Fri 21:00 10:00
after-hours day Sat 21:00 10:00
Configure COR lists
COR lists are the true call control feature on CME, and, as you may guess, it's not easy to explain in a hurry...
Basically, COR lists are the means to determine what destinations are allowed to any extension to call or being called.
In the most basic operative way, they work by "tagging" or "labeling" calls depending on the extension who placed the call:
Think of those tags or labels as a kind of tokens, grants, or permissions the call got assigned. Lists of labels can be tailored, with one or several labels within them, that way, one or multiple labels can be assigned to a call at once.
ephone-dns (i.e extensions) got assigned one of those lists in either incoming or (more usual) outgoing direction. By doing so, calls initiated or ended by that extension got the all the labels/tags of that list applied to it automatically.
In parallel to this, cor lists (usually lists with just a single label) are also assigned to dial-peers. By doing so, a call that matches the dial-peer got its list of labels examined, so, in order for the call to be further processed the label (or labels) in the dial-peer list must be among the labels on the call list.
Let's see an example:
First we need to "declare" our set of custom labels/tags
dial-peer cor custom
name International
name Local
name Emergency
Here I'll be playing with the International calls, the fraud favorites. Normally that list would be longer, declaring all kinds of dial-peer for call types declared on the system, so most (if not all) dial-peers got its label applied, and control can be gained...but here's just an example...
Now I'll declare a single label, cor list, named "CallInternational", that includes just the "International" tag.
dial-peer cor list CallInternational
member International
By assigning the CallInternational cor list to a dial-peer, any call to be processed after matching it, would be prior required to have the label/tag "International"
dial-peer voice 100 pots
corlist outgoing CallInternational
destination-pattern 000T
port 0/0/0
forward-digits all
Now, outgoing international calls are restricted!!! But, how it works to control granting or denying them? ... here we go...
Let's create a pair of new cor lists, name "Limited" and "Unlimited"
dial-peer cor list Limited
member Local
member Emergency
!
dial-peer cor list Unlimited
member International
member Local
member Emergency
As you see, assigning the cor list "Unlimited" implies getting the International label/tag assigned/applied, while on the "Limited" cor list case it would not.
Now if we apply the "Limited" cor list to an ephone-dn (an extension) we are denying it to place International Calls
ephone-dn 10 dual-line
number 1001
corlist incoming Limited
Note here how confusing (at least for me) is the usage of the "incoming" term... Here "incoming" means "this cor list is applied to a call that comes from ephone-dn 10" ... so its outgoing!!!
If the dialed number at extension 1001 matches the dial-peer 100, to international destination, it would be required to have the "International" label/tag. Since it would only have "National" and "Emergency" labels/tags the call will be denied!!!
Given an extension such as:
ephone-dn 20 dual-line
number 1002
corlist incoming Unlimited
If that extensios would dial the same international destination number, the call would be allowed to proceed.
So, Hope this may help someone to save some buck out of the rogue PBXs running on the Internet...
Have a happy lab!!!