• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2585
  • Last Modified:

Securing Cisco Router Port UDP 5060

Lately our main line has been getting calls from internal extensions that we don't have in the phone system.  All of our extensions are in the 300's, but we get calls to the main line from extension 100. When we answer the phone, there is no one there. This can happen every two hours or every 20 minutes.

I called Fonality (VOIP provider) to explain the issue, and they told me that we are  getting spam calls. They say that spam calls ring the server using the public IP address of the server, using UDP port 5060 in the firewall.

I was advised to lock down UDP port 5060 and to create a whitelist for our remote phones (telephones outside the office) and for the ISP carrier. I think that closing port UDP 5060 is the easiest way to resolve this issue but we will encounter registration of the remote phones to the server and registration of the phone server to the VOIP carrier using port 5060.

In conclusion, I need to allow access to port 5060 UDP only to our internal VOIP server and remote phones. Right now we are allowing all traffic I believe on UDP 5060. Please see attachment file for configuration.

We are using a Cisco 2901 router, and we only use the router's built-in firewall.

Network Organization: ISP Gateway-> Cisco Router -> Switch -> VOIP Server

I am writing here to get step-by-step instructions as to how to make the modifications that I was given by Fonality. The router uses Cisco's IOS and I need every command that will be required to accomplish this.

Thanks a lot!
Configuration.txt
0
CompuHero
Asked:
CompuHero
  • 7
  • 5
1 Solution
 
asavenerCommented:
Can you run the following command and provide the output?

show run interface GigabitEthernet0/1


Also, do you have the IP addresses of your remote phones?
0
 
agonza07Commented:
Yeah, looks like you will need to lock down your firewall by only allowing port 5060 to be accessed by certain IPs.
0
 
CompuHeroAuthor Commented:
@ asavener:

Here is the output that you requested:

Building configuration...

Current configuration : 210 bytes
!
interface GigabitEthernet0/1
 description $ES_LAN$$FW_OUTSIDE$
 ip address XX.XX.XXX.234 255.255.255.248
 ip nat outside
 ip virtual-reassembly
 zone-member security out-zone
 duplex auto
 speed auto
 !
end

Open in new window

0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
asavenerCommented:
Yup.  You need to apply an access-list to your outside interface.
0
 
CompuHeroAuthor Commented:
@ asavener:

Can you tell my how to do that step-by-step? I would appreciate your detailed help on this matter. I do have the IP address of the remote telephones. For demonstration purposes lets assume that they are as follow:

1. 70.58.944.100

2. 70.58.944.102

3. 70.58.944.103

4. 70.58.944.104


Thanks!
0
 
asavenerCommented:
The difficulty here is to not break something else that is already working, and not to introduce additional vulnerabilities.

So, this is designed ONLY to address the issue of the phone calls, an is not by any means a recommended practice:

ip access-list extended FW-G0_1_v01
remark allow SIP from certain addresses
permit udp host 70.58.944.100 any eq 5060
permit udp host 70.58.944.102 any eq 5060
permit udp host 70.58.944.103 any eq 5060
permit udp host 70.58.944.104 any eq 5060
remark
remark block SIP from all other addresses
deny udp any any eq 5060
remark
remark Allow all other IP traffic
permit ip any any

interface g0/1
ip access-group FW-G0_1_v01 in
0
 
CompuHeroAuthor Commented:
@ asavener:

Did you take a look at the "Configuration.txt " file that I attached to the original question? I would like to know if you can spot something that could break once I enter the commands that you suggested.

Let me know.

Thanks!
0
 
asavenerCommented:
That's why I constructed the access list the way I did.  

With no access list applied, all traffic is currently allowed.  All I did was block one particular port/service and allowed all other traffic.  This should fix the issue of the spam SIP calls, without blocking any other services.
0
 
CompuHeroAuthor Commented:
@ asavener:

Thanks a lot! I will try this today after regular business hours. I have been able to bypass the issue temporarily by resetting the Fonality Server. It seems that resetting the server reduces the amount of spam calls we get to approximately 10 per day.
0
 
CompuHeroAuthor Commented:
@ asavener:

All your steps worked beautifully! You have given me by far the best answer/help that I have ever gotten from this website. With previous answers that I have received for other questions, I had to always correct other problems caused by the answer or figure out how to make it work correctly. Yours worked right from the get-go.
0
 
CompuHeroAuthor Commented:
@ asavener:

Just one more thing if I may. It is possible that I might have to modify one of the telephone IP addresses from above. Let's say for example that 70.58.944.100 now needs to be changed to 24.69.456.64. How could I do that one number modification?

Thank you!
0
 
asavenerCommented:
My preferred way of editing an access list is to create a new access list with the updated lines, and then apply the new access list to the interface.  That's why I put in version numbers.

There's a number of reasons for this.  One, I don't inadvertently modify an active access list that controls my access to a router.  Two, I have a history that I can refer to, and I can identify exactly what change was made.


ip access-list extended FW-G0_1_v02
<the rest of your access list>

interface g0/1
ip access-group FW-G0_1_v02 in
0
 
CompuHeroAuthor Commented:
@ asavener:

Thank you! Your help is much appreciated.
0

Featured Post

 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

  • 7
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now