Great Office - Hummig KG Posted December 8, 2013 Report Share Posted December 8, 2013 Hello everyone, I'm getting lots of eMails from our PBX with following message (where xx.xxx.xxx.xxx is the IP of my PBX): Source address for "205" <sip:205@xx.xxx.xxx.xxx:5060>;tag=8351913a6a365 has changed from udp:178.238.235.144:5061 to udp:178.238.235.144:5082 The attachment enclosed shows: REGISTER sip:xx.xxx.xxx.xxx:5060 SIP/2.0Via: SIP/2.0/UDP 178.238.235.144:5082;branch=z9hG4bK8351913a65d52461352a4d206;rportFrom: "205" <sip:205@xx.xxx.xxx.xxx:5060>;tag=8351913a6a365To: "205" <sip:205@xx.xxx.xxx.xxx:5060>Call-ID: 13a65d52-c9894613-52a4d206@xx.xxx.xxx.xxxCSeq: 1 REGISTERContact: "205" <sip:205@178.238.235.144:5082>User-Agent: VaxSIPUserAgent/3.1Expires: 1800Max-Forwards: 70Content-Length: 0 So far nothing fancy, except, that there is no extension 205 at all! A few minutes I get the same eMail, but with other extension numbers all not set up on this PBX. I've checked the call history and there are no calls from those extensions, but I get nervous that obvoiusly someone is hacking my pbx. How to get rid of this situation? Is it possible that someone can register an extension just by SIP-Connect without creating the extension before at admin's interface? Regards Quote Link to comment Share on other sites More sharing options...
Vodia support Posted December 8, 2013 Report Share Posted December 8, 2013 The user agent VaxSIPUserAgent/3.1 reports the change in ports and the pbx is just reporting it, This happens on xlite smart phone application as well the Xlite keeps changing ports there nothing that can done on the PBX side, maybe VAX as some information on this item? Quote Link to comment Share on other sites More sharing options...
Great Office - Hummig KG Posted December 9, 2013 Author Report Share Posted December 9, 2013 If the VaxSIPUserAgent would be one of our registered extensions, everything would be fine and the pbx's report changing of port could be ignored. Unfortunately neither the client's IP-Adress belongs to one of our branch offices nor does that extension exists on the pbx. So due to this change in port Information we stubled about, there is something (successfully?) registered on our pbx we didn't had allowed to be. Never heard about a VaxSIPUserAgent. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted December 9, 2013 Report Share Posted December 9, 2013 Make sure that you have the password policy set to medium or strong. Users tend to choose trivial passwords, for example extension numbers, 1234 or password. Then a scanner can easily find a password and get going. If you have the password policy set, the web interface will highlight those extensions that need to change their passwords. Usually that is already enough so nobody can hack the system. On the trunk side, take the warning serious to put in an outbound proxy, or even better explicitly specify where the traffic is coming from. Unfortunately the ENUM specification must allow it that INVITE can come from anywhere to the PBX. Especially when the trunk is able to route calls out of the PBX again, that is very important. The message that the registration has changed is actually misleading. If I remember correct, it was changed at some point. The PBX must keep an internal object for the REGISTER request, and if the next request comes in fast enough, it reports that the address has changed for that address.But it does not mean that there is an active registration or that resource is allowed to place a call. If the scanner has not guessed the password right, it cannot place a call. Quote Link to comment Share on other sites More sharing options...
Great Office - Hummig KG Posted February 3, 2014 Author Report Share Posted February 3, 2014 Again, we have the same issue. We got just informed that there are registrations from the United States (noone of our users is there) are done. We get this message (where x.x.x.x is the IP of our PBX): REGISTER sip:x.x.x.x:5060 SIP/2.0Via: SIP/2.0/UDP 192.69.88.146:5066;branch=z9hG4bK5522310192a69a552ef6db8;rportFrom: "5005" <sip:5005@x.x.x.x:5060>;tag=552231082cfTo: "5005" <sip:5005@x.x.x.x:5060>Call-ID: 310192a-10bf69a5-52ef6db8@x.x.x.xCSeq: 1 REGISTERContact: "5005" <sip:5005@192.69.88.146:5066>User-Agent: VaxSIPUserAgent/3.1Expires: 1800Max-Forwards: 70Content-Length: 0 I've I understood you right, the only way we have, is to keep our passwords secure. Is there a way to retrieve from the above message, which account of which tenant has been cracked? Not one of our multi-tenant pbx has an accout 5005. On the trunk side, take the warning serious to put in an outbound proxy, or even better explicitly specify where the traffic is coming from. Unfortunately the ENUM specification must allow it that INVITE can come from anywhere to the PBX. Especially when the trunk is able to route calls out of the PBX again, that is very important. Do you mean settings made on the Trunk-Provider Side or settings on the Trunks of the SnomOne? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 3, 2014 Report Share Posted February 3, 2014 I've I understood you right, the only way we have, is to keep our passwords secure. Is there a way to retrieve from the above message, which account of which tenant has been cracked? Not one of our multi-tenant pbx has an accout 5005. Those scanners try out various accounts. Having found the PBX does not mean that they have found a valid account of the right password. They will probably keep on scanning for some time. But if you don't use the name "localhost" it will be difficult to find a valid account and domain name unless there is a human involved that knows what domains are being hosted. And choosing a good password will make it very hard to find valid credentials. Do you mean settings made on the Trunk-Provider Side or settings on the Trunks of the SnomOne? On the PBX side (now called Vodia PBX). Setting the outbound proxy or listing the IP addresses makes sure that the PBX associates only those addresses with traffic on that trunk. Unfortunately the IETF was envisioning that anybody could call from anywhere (ENUM), and we still have that in the product if you leave the outbound proxy open. A JavaScript warning should pop up if you do that. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.