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

[dmendoza]

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?

[heshengchun]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Interesting, you can test without building POTS dial-peer.

[heshengchun]

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]

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]

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]

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