Urgent!!!! Voice Gateway was hacked, were made thousand of L.D Calls

Unanswered Question
Nov 22nd, 2008

I have several 2800 Voice Gateways in several regions. How can I protect my H.323 GW? these Gateways have public IP addresses. Can I control or Authenticate my VOIP Gateways in order to eliminate a rogue Gateway can connect to my Gateway and they can make calls?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (2 ratings)
wong.jason Sun, 11/23/2008 - 16:10

You need to at a minimum create an ACL to prevent H323 traffic that originate from the internet from going into your gateway and only allow those from your sites.

heshengchun Sun, 11/23/2008 - 18:21

As far as I know. GK is the only solution. Access-list can not prevent Dial peer hacking

tim.giles Mon, 11/24/2008 - 03:02

Hi,

I don't know whether this is a possibility but you could add a gatekeeper to authenticate requests via AAA? That way all the gateways would have to securely register with the gatekeeper.

This can also be intergrated with a radius server (i.e. ACS) if you have one?

dmendoza Mon, 11/24/2008 - 07:23

I appreciate you response, would you have a link with a example of how integrate the GK with CSACS in what version of CSACS is?

daniel.fuchs@da... Mon, 11/24/2008 - 07:54

Do you know the IP address of all gateways authorize to send calls (signaling) to the other one? if so, you may consider an access-list.

if the answer is yes, you may consider somthing limiting access per port per IP address for example. here is some port information to assist you:

H.323/H.225 = TCP 1720

H.323/H.245 = TCP 11xxx (Standard Connect)

H.323/H.245 = TCP 1720 (Fast Connect)

H.323/H.225 RAS = TCP 1719

SCCP = TCP 2000-2002 (CM Encore)

ICCP = TCP 8001-8002 (CM Encore)

MGCP = UDP 2427, TCP 2428 (CM Encore)

SIP= UDP 5060, TCP 5060 (configurable)

I get it from http://www.cisco.com/en/US/tech/tk652/tk698/technologies_configuration_example09186a0080094af9.shtml

regards,

daniel

heshengchun Mon, 11/24/2008 - 08:07

Daniel,

Access-list is not good idea to prevent dial peer hacking. Here is one scenario - Both A and B need send H.323 calls to C, how can you use access-list to prevent A hacks B's account in C?

daniel.fuchs@da... Mon, 11/24/2008 - 08:44

Jack,

I was considering an outside attacker and not someone from the company. not someone from this cloud of Cisco Gateways.

if the problem is inside the network, what do you think about AAA (radius)?

heshengchun Mon, 11/24/2008 - 08:54

Daniel,

The scenario I mentioned is indeed for hacking from outside. I thought AAA is not power enough to prevent such attack. Could you advise how to use AAA in such scenario?

isahonen Tue, 11/25/2008 - 01:28

HI

You can use source-ip based dial-peer to using voice source-group, access-list and translation rules.

Example:

voice source-group customer1

access-list 50

translation-profile incoming 50

voice source-group customer2

access-list 40

translation-profile incoming 40

rgds,

Ismo

dmendoza Tue, 11/25/2008 - 08:15

I was looking for a complete example of this command voice source-group, but I dont find it. So this command is for using a ACL where you specify the IP of Remote Gateway in order to ensure only this Gateway can do calls for the translation profile?

Could send me more details how use this command, by the way I have a CS ACS for AAA.

The challenge is be able to identified or permit the uses of the prefix for client but only from a known ip address of GW.

isahonen Wed, 11/26/2008 - 00:48

Below are simple example, where prefix 7 or 8 are added to using that feature.

access-list 1 permit 1.2.3.4 0.0.0.255

access-list 2 permit 3.4.5.6 0.0.0.255

voice source-group 1234

access-list 1

disconnect-cause invalid-number

translation-profile incoming 1

voice source-group 3456

access-list 2

disconnect-cause invalid-number

translation-profile incoming 2

voice translation-profile 1

translate called 1

voice translation-profile 2

translate called 2

voice translation-rule 1

rule 1 /^1\(.*\)/ /81\1/ type any subscriber plan any isdn

voice translation-rule 2

rule 1 /^1\(.*\)/ /71\1/ type any subscriber plan any isdn

dial-peer voice 1 voip

destination-pattern 8T

dial-peer voice 2 voip

destination-pattern 7T

heshengchun Wed, 11/26/2008 - 06:00

I think this solution is good for IP2IP scenario, what about IP->TDM?

Suppose ISDN T1-A must take calls from IP 1.2.3.4/24 and ISDN T1-B must take calls from IP 3.4.5.6/24.

daniel.fuchs@da... Wed, 11/26/2008 - 06:14

sir,

you can send calls from these gateways with different tech prefixes and strip in the correct E1 to deliver the calls.

Regards,

Daniel

heshengchun Wed, 11/26/2008 - 06:18

Daniel,

Be patient. what you described is exact what I called dial-peer hacking. Do you know how much money IDT lost due to the dial-peer ( tech prefix ) hacking?

daniel.fuchs@da... Wed, 11/26/2008 - 06:22

Sir,

Maybe I'm missing something here but if you combine the tech prefix match with the voice source-group command (or access list), you will limit the access to the gateways only to IP addresses that belong to your company and tech prefix will be used not to block calls but to deliver it correctly in a specific E1 or T1.

regards,

Daniel

heshengchun Wed, 11/26/2008 - 06:33

In fact we only need one POTS dial-peer to terminate VOIP->TDM call, therefore simple access-list and tech prefix open hole for the dial-peer hacker. As for how to use voice source-group to prevent such attack, I do need advise.

daniel.fuchs@da... Wed, 11/26/2008 - 08:44

I try this command in a similar equipment and it works like this:

to block a specific IP, returning to these calls user-busy, and allow all other IPs to send calls, you can build an access list like this:

access-list 1 deny x.x.x.x

access-list 1 permit any

than using the command suggested by our colegue, we include the access list reference and the disconnection cause desired for the block calls:

voice source-group secured

access-list 1

disconnect-cause user-busy

you can invert the access list and allow just some specific IP addresses to send calls.

I hope this can be useful for the subject.

regards,

daniel

heshengchun Wed, 11/26/2008 - 08:57

let me repeat -

Suppose ISDN T1-A(for long distance) should only take calls from IP 1.2.3.4/24 and ISDN T1-B(for local) should only take calls from IP 3.4.5.6/24. How can you do to prevent calls from 3.4.5.6 to dial long distance call?

daniel.fuchs@da... Wed, 11/26/2008 - 09:28

suppose the termination gateway IP is 9.9.9.9

at gateway 1.2.3.4, dial-peer should be something like:

dial-peer voice 100 voip

destination-pattern 0T ! if numbers start with 0 for example

session target ipv4:9.9.9.9

tech-prefix 100#

at gateway 3.4.5.6, dial-peer should be something like:

dial-peer voice 200 voip

destination-pattern .T ! if numbers start with any digit for example

session target ipv4:9.9.9.9

tech-prefix 200#

at local gateway we will put

! secure to just receive calls from these classes of IP:

access-list 1 permit 1.2.3.4 255.255.255.0

access-list 1 permit 3.4.5.6 255.255.255.0

access-list 1 deny any

voice source-group secured

access-list 1

disconnect-cause user-busy

! each dial-peer to each e1:

translation-rule 100

rule 0 100#0 0

! this is in a very extended way and not allowing 0

translation-rule 200

rule 0 200#1 1

rule 1 200#2 2

rule 2 200#3 3

rule 3 200#4 4

rule 4 200#5 5

rule 5 200#6 6

rule 6 200#7 7

rule 7 200#8 8

rule 8 200#9 9

rule 9 200#1 1

! terminate in ISDN T1-A

dial-peer voice 100 pots

translate-outgoing called 100

port 1 (should replace by correct port identification)

! terminate in ISDN T1-B

dial-peer voice 200 pots

translate-outgoing called 200

port 2 (should replace by correct port identification)

heshengchun Wed, 11/26/2008 - 09:37

suppose I can access 3.4.5.6 and I want to dial free long distance, so I add this dial-peer

in 3.4.5.6

dial-peer voice 300 voip

destination-pattern .T

session target ipv4:9.9.9.9

tech-prefix 100#0

daniel.fuchs@da... Wed, 11/26/2008 - 09:49

Jack,

This was in the supposition that you have gateways proteceted but even with that, if you go back to "isahonen" example, you can do to different voice source-group, associate a different access list with each of them and than associate different voice translation-profile with each one:

access-list 1 permit 1.2.3.4 0.0.0.255

access-list 2 permit 3.4.5.6 0.0.0.255

voice source-group 1234

access-list 1

disconnect-cause invalid-number

translation-profile incoming 1

voice source-group 3456

access-list 2

disconnect-cause invalid-number

translation-profile incoming 2

voice translation-profile 1

translate called 1

voice translation-profile 2

translate called 2

voice translation-rule 1

rule 1 /^1\(.*\)/ /81\1/

voice translation-rule 2

rule 1 /^1\(.*\)/ /71\1/

heshengchun Wed, 11/26/2008 - 10:17

Daniel,

Did you really test "isahonen" example before drawing conclusion? BTW, 3.4.5.6 is my GW and I'd like to test security of 9.9.9.9

daniel.fuchs@da... Wed, 11/26/2008 - 15:25

yes, I test the following exact configuration:

voice translation-rule 100

rule 1 /^100#81/ /81/

rule 2 /^.*/ /8888888/

voice translation-rule 200

rule 1 /^200#81/ /81/

rule 2 /^.*/ /88888888/

voice translation-profile 100

translate called 100

voice translation-profile 200

translate called 200

access-list 1 permit 1.2.3.4 0.0.0.0

access-list 1 deny any

access-list 2 permit 3.4.5.6 0.0.0.0

access-list 2 deny any

voice source-group secured

access-list 1

disconnect-cause invalid-number

translation-profile incoming 100

voice source-group secured2

access-list 2

disconnect-cause invalid-number

translation-profile incoming 200

this example is based on calls to country code 81 and if it's not 81, I block it, translating it to 888888.

regards,

daniel

heshengchun Wed, 11/26/2008 - 21:57

I will test source-group as well. Again, simple access-list and tech-prefix combination without voice source-group definitely has security issue.

daniel.fuchs@da... Thu, 11/27/2008 - 04:26

if you can not guarantee that your gateways will not be invade and have it's configurations changed, I agree with you.

let me know your tests.

regards,

daniel

heshengchun Thu, 11/27/2008 - 07:27

When we talk about security of GW 9.9.9.9, GW 3.4.5.6 could be any 'innocent' or 'bad' individual. Therefore in security discussion of termination GW, we should consider all potential scenarios.

Regards,

daniel.fuchs@da... Thu, 11/27/2008 - 07:30

Jack,

I agree. I mention that because based on the problem description I was considering it as an enterprise network and not a voice wholesaler like us.

Regards,

Daniel

dmendoza Thu, 11/27/2008 - 08:35

Thanks for yours comments and interesting examples, but nobody has made much examples or links how configure a Gatekeeper with Authentication with AAA using CSACS. Is it a good alternative, if the mayority of the Gateways have Publics IP Address?

Is it possible to Register and Authenticate H323 Routers and SIP end points with GK at the same time? Does Cisco GK only support H.323 or can support SIP endpoints?

daniel.fuchs@da... Thu, 11/27/2008 - 08:56

Sir,

I didn't understand that your objetive was GK with ACS.

regarding GK, based on what I know, it's just for H.323.

regards,

daniel

dmendoza Thu, 11/27/2008 - 09:29

I found this about GK:

Gatekeeper Features

The following sections describe the main features of a gatekeeper in an H.323 network:

• Zone and Subnet Configuration

• Terminal Name Registration

• Inter-Zone Communication

• Endpoint Identification via RADIUS/TACACS+

• Accounting via RADIUS/TACACS+

• Inter-Zone Routing Using E.164 Addresses

I was wodering if someone has configured this capabability :

• Endpoint Identification via RADIUS/TACACS+

This feature apply for users for billing porpouse in a internal Network or could be used to authenticate Gateways, too?

I have a billing system but I am not Authenticating Gateways, my endpoints in my case are others Gateways with TDM E1/T1 using others Gateways not user with a only one Phone.

Nicholas Matthews Sat, 12/13/2008 - 15:07

I think this needs some clarification, because it can be a very important issue.

First, I would check out this tip:

http://www.cisco.com/en/US/products/sw/voicesw/ps4625/products_tech_note09186a00809dc487.shtml

Then, you need to understand these basics:

H323 will respond to any request on any interface on TCP port 1720 by default. This applies even if you have the bind command.

SIP will respond on any IP address on UDP/TCP 5060 by default as long as the router has a voice-port. If you bind the media address, SIP will only respond on that address.

This means in short - even if you're running an H323 only gateway, you are still capable of bouncing incoming SIP traffic out your dial peers. It is very common to see a H323 only gateway with a .T or 9.T pots dial peer, and attackers hit the public IP address, it matches an incoming voip dial peer (or dial-peer 0), and then the wildcard matches the PSTN pots wildcard dial peer.

If you have a public IP address, make sure that you disable all SIP traffic on TCP/UDP ports 5060. You can use 'show tcp' or 'show ip socket' or 'show udp' to see some of the open ports.

HTH,

Nick

Actions

Login or Register to take actions

This Discussion

Posted November 22, 2008 at 2:36 PM
Stats:
Replies:34 Avg. Rating:5
Views:3022 Votes:0
Shares:0
Tags: No tags.