HOWTO: Thwarting SIP Scanners during Set-up
Mango:
I agree. The only way for a cracker to get past it would be to guess your AuthUserName. That would take forever, and there would be no point.
If you're not registered to a service provider, you can still set an AuthUserName if you want to. Also, even if you don't use DMZ, it's still possible for the port to be open, if your router is not a "restricted cone NAT" type. If your router IS a restricted cone NAT type, you don't have to worry because the router will block inbound SIP traffic except from your VoIP service provider.
claude:
{>(123456):ph1,ph2},{(514xxxxxxx):aa},{ph1,ph2,pp1(ob500xxxxxx),sp31514xxxxxxx)}
123456 is my AuthUserName in voip.ms 123456 is fake number for this post.
my probleme is i do not received call to my sp3514xxxxxxx whe a call is placed to my voip.ms phone number
before i had (514xxxxxxx):aa},{ph1,ph2,pp1(ob500xxxxxx),sp31514xxxxxxx)}
ianobi:
This rule {>(123456):ph1,ph2} is matching all CallerIDs so the other rules do not get used. I think there is also a missing "(" after sp3 in the last rule - maybe just a typo. I think this would work for you:
{(514xxxxxxx):aa},{>(123456):ph1,ph2,pp1(ob500xxxxxx),sp3(1514xxxxxxx)}
Shale:
I was considering something brief as a method 5. Here was my initial idea for a description:
=============================================================
5. Have the OBi behind a Restricted Cone NAT router. I wish there was a list of such routers and settings to implement this. I don't even know what the word "cone" means in this context. We could use a page or thread describing this method that will probably need new hardware. This method seems complex to understand.
===========================================================
I fear that at this point, there is not a clear how-to statement that I could make. If I could refer to a nice list of routers along with either the settings to go restricted-cone or the statement that the router is restricted-cone, this would not yet be appropriate to this thread. With restricted cone routers, an outside server can only send packets in if you have previously sent that server a packet. There are varieties: Port-restricted cone NAT and Address-restricted cone NAT. http://en.wikipedia.org/wiki/Network_address_translation
So at this point, I don't think "method 5" is suitable to add to the list. The SIP scanner thwarting methods list needs simplification more than it needs comprehensiveness.
Felix:
Quote from: Shale on March 31, 2013, 12:27:40 pm
So at this point, I don't think "method 5" is suitable to add to the list. The SIP scanner thwarting methods list needs simplification more than it needs comprehensiveness.
+1
from wikipedia:
This terminology has been the source of much confusion, as it has proven inadequate at describing real-life NAT behavior. Many NAT implementations combine these types, and it is therefore better to refer to specific individual NAT behaviors instead of using the Cone/Symmetric terminology.
Neither OpenWRT nor DD-WRT mention anything about restricted-cone in its documentation. It will just confuse the reader without adding much value. I can't think of use-case where this approach would be best...
Navigation
[0] Message Index
[#] Next page
[*] Previous page