Jump to content

Securing trunks?


RobertoAchab

Recommended Posts

Hello,

recently I put a pbx on a public address, but as soon as I did it I was submerged by false call from an extension that didn't even exist.

I found documentation about the fact that this behavior is caused by someone that impersonate e trunk.

Now my question is how can I protect my trunk? I only have one patton and I don't want any other trunk, so is there any option in the pbx so that it asks for the trunks to be pre-configured, or that they have to do a signon?

Also, is there a step by step guide somewhere about securing a pbx?

i can use ten letter random passwords for my extensions, but if someone can simulate a trunk all my efforts are useless...

 

Regards

(I have a 4.5.0125 snomone pbx, I forgot to mention)

Link to comment
Share on other sites

Hello,

thanks for the answer, giving a public ip address to the pbx is a solution to avoid using VPNs, the company I work for has mostly tele-workers and VPNs "instability" sometimes gives us problems.

This is the reason why I can understand that "closing" the pbx from unknow ip addresses should secure it, but I don't want to do it, because teleworkers often have dinamic ip addresses (and sometimes they connect from their grandma' house... :-)).

I already read the suggestion to set an outbound proxy, I'm attaching my only trunk configuration, but I can't understand how this can prevent internet-connected hacker-accounts to place calls.

I can filter the outgoing phone numbers on the patton itself, obviously, but I'd prefer to keep all the "security" configurations on the pbx

Link to comment
Share on other sites

...btw, in the few hours I had the public pbx xlite clients did correct login and placed phone calls, while some "behind double-NAT" SNOM hw phones didn't work or only received calls, but didn't call out.

In the registration message of these phones the subnet declared was 10.176,x.x, I don't even know how the phone knew it, the phone was on a 192.168.x.x network, NATted behind a 10.176 by the provider (that thing explains the term "duble natted" :-)), then it was natted again to a public 93.x.x.x that was finally shown in the registration message as the real ip from which the phone came.

The Xlite in the very same subnet showed the original 192.168.x.x ip in the registration instead (and 93.x.x.x as the real one) and it worked well.

os there any way to say to the snom phone (821s and 3xxs) what to declare as the phisical p address?

Should I use a STUN? and in this case which is a working free STUN?

 

Thanks in advance for the answers.

Link to comment
Share on other sites

Trunks are not extensions. If it absolutely normal to link trunks to specific IP addresses.

 

Extensions can then still register from anywhere, if they have the right password. If you run your PBX on public IP, it is very important to have users pick "good" passwords. This can be enforced by the password policy in the settings on the PBX (admin level).

 

Don't use STUN. STUN is just a hack for servers that don't have a SBC built in and it causes more problems than it helps. Just register directly to the PBX, which will automatically detect if the device needs help with NAT traversal.

Link to comment
Share on other sites

Hello,

I can have the strongest pasword policy (I was planning to have a process on our crm to change passwords automatically every weeks) but the hacked calls came from non-existing numbers(100 and 1010, my addressing doesn't use 1xx numbers), vhat can I do to tell the pbx that it can place calls only if they come from rgistered accounts?

It seems to me like fighting mail relay, unortunately pbxs have a lot less tools than mail servers...

 

Regards

Link to comment
Share on other sites

Under status there is a setting called phones, here you can see all the IPs that are remote to the system, you can also add them to the access list. It's advisable to set up the email notification so that you can be updated when a IP has been blacklisted from the system there is no clean way of doing this but the sad reality is there are SIP scanner and SIP vicious programs built on hacking the PBX that's why the access list is your best bet in protecting the integrity of the PBX.

Link to comment
Share on other sites

Ok, i knew, but my role in the company is to give support to customers of a couple of programs we distribute, my boss decided that we are spending too mush time for this thing to work, so I think we're going to live with VPNs for a while and then, in some months we're going to migrate to an itsp, so those will be someone else's problems.

Link to comment
Share on other sites

... vhat can I do to tell the pbx that it can place calls only if they come from rgistered accounts?

 

Tell the PBX where the trunk traffic comes from. This is done by specifying an outbound proxy and/or listing the IP addresses where trunk traffic comes from. It should be really easy to do that. If you have JavaScript enabled on your system, the web browser will actually warn you if you don't have a outbound proxy set up.

Link to comment
Share on other sites

I checked this thread again and saw that you are still on version 4. Also in version 4, you need to specify the trunk outbound proxy and you may specify the inbound addresses. Nothing different here.

 

However as far as I remember version 4 had the problem that as soon as the source matches any account in the domain, the call was accepted. That explains why your service flag is allowed to make calls in your domain. However the damage should be limited as the service plan does not have a dial plan and thus the calls will always remain in the domain. The hacker probably tries a couple if numbers, and must find out eventually that the calls do not terminate anywhere useful and give up. If the hacker finds an extension that would be able to make a call, that person has to guess the password. If the passwords are not trivial (e.g. account number = password), then the system is still safe. We have changed that in version 5, so that only extensions or trunks can make calls.

Link to comment
Share on other sites

  • 2 weeks later...

Hello,

I'm glad to read that calls couldn't be placed, as I didn't understand from the nightly report if they were only trials or real calls.

Unfortunately they came from "100" and "1010", those accounts don't exist on my pbx, they aren't service flags, nor any other things.

I assumed that they were seen as coming from a trunk for this reason.

I think that this night I'm going to temove the outbound proxy and try to call from home to the office, if it fails then I'll know that without being configured a trunk can't reache the pbx.

I'm also going to evaluate upgrading to 5, if I can find the spare time to test it.

 

Regards

Link to comment
Share on other sites

Hello,

my pbx has only one trunk and it's confiured as an outbound proxy, the test I did was only for me, to be sure that without a trunk defined calls can't reach the pbx.

The password for my extensions are randomly generated and periodically changed, so I think they are quite secure.

Step by step I'm understanding how to secure my pbx, the only think I still can't understand is why the hacked calls came from accounts 100 and 1010, while those accounts don't exist (as phone numbers, service flags, ivr.... they don't exist at all).

I can understand why hackers scanned whose numbers, because they usually are the desk's numbers, but my internal addressing has 9xx numbers, so where did pbx take "100" account?

Is it so standard that it exists also if it's not defined as an account?

 

Regards

Link to comment
Share on other sites

The best defense for these types of scenarios is using the access list on the PBX by allowing the users whom are tied to the system. The SIP scanners only send request to the PBX and if a SIP request is answer then they will start guessing sip password ect or just simply by sending a bogus invite to the PBX which result in the trunk provider trusting the source. The access list will automatically block these request by automatically blk listing these external IP.

Link to comment
Share on other sites

Hello,

as I repeated a couple of times I was testing to move the pbx on a public ip because teleworkers would have great advantage in not using VPNs anymore, but they are connecting from dynamic IPs, so I can't use access list...

well, I can't use them now, I was just thinking to ask developers if they can configure access list of the pbx as they do with hunt groups and phone calls from our CRM... but that is science fiction for now :-D

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...