Ports, and the endless confusion they cause


Any one hardware mac address assignee can provide 82313216 individual possibilities, firewalls with conntracking enabled can count the connections made and failed out of those 82 million possibilities so a decent one will notice that anything more than a few per second is probably not friendly, as a consequence that IP can be denied for at least a sensible time.

If you care for one that can and will do that perhaps CSF?


But again. look at your log files, show me one attempted access to your domain url ( not your IP address)


Perhaps. But it doesn’t take a wizard to eliminate the majority of those very quickly. A cursory check of deployments shows every Sangoma S-series MAC starts with 00:50:58:5. 16^5 is 1,048,576. It wouldn’t take long for a bot net to run through those.

I would not leave provisioning open to the entire internet minus a way to do what you say: Monitor connection requests to the internal provisioning endpoint and cut off after a very small number of attempts over a short period of time.


No, the vendor part is the first three “00:50:58” the device part will have any of FF*FF*FF possibilities.

If your firewall doesn’t notice failed attempts to open these connections, you have a limp firewall, fix that.

But pragmatically, just show one attempt to any match on that URL, again, these guys won’t use your domain name they only have your IP but you should be dropping any IP only requests

If you remain queazy, most decent phone vendors now allow you to encrypt your base config while provisioning but of course your extensions will need hose certs installed. Everyone is saying ‘it’s too hard’ this is obviously not for this audience


Sure, but that should be a ‘last resort’ defense. Primary protection methods include:

  1. Only accept requests for correct domain name (won’t work with old phones without SNI).
  2. Put provisioning files in an obscurely named sub folder.
  3. Encrypt provisioning files with a key entered into the phones manually, or by an initial provision.
  4. Have server verify the client certificate factory-installed in the phone.
  5. Protect provisioning files with a username and strong password.

Some of the above are relatively weak, but much stronger than just putting provisioning on an obscure port.


All true, most as already noted, particularly your point 1, but the thread here is less bounded, apparently nobody is comfortable with changing the registration port, so this whole provisioning thing is likely moot for this audience until they “see the light”, after they ‘see the light’ they will no longer see the dark UDP/5060 crap (I correct myself, they will see it, but it will not go anywhere) , it’s just that simple.


The point of the thread, which has largely been forgotten, is base understanding of how ports work. I recognize that the topic is basic networking for many people but if anyone wants to discuss it further please jump back in. The hope was to help people who get all puzzled about things like:

  • Why is pjsip 5060 and chan_sip 5160 and what does that mean?
  • I set my ATA to use port 5160 but it’s not connecting to my pbx, why?
  • My extensions are using pjsip but not registering, and here are a bunch of log lines showing chan_sip, help.


Totally agree with @billsimon , and exactly why I posted

For UDP and TCP , to change the port to listen on (I suggest that port NNNNN > 20000 < 60000 are good choices) :-

GUI -> Asterisk SIP settings -> sip settings (presumable chan_pjsip nowadays) -> Port To Listen on

To change the Phone to that , use the same number in the Register Port field or in that field’s absence add “:NNNNN” to the registrar address.

If you can use TLS (good idea) just stay with 5061 and get your certs in a row,

Note the “presumable chan_pjsip nowadays” that would reveal by default the dastardly 5060, YOU CAN CHANGE THAT!!!

Addendum, your firewall might appreciate you editing /etc/services to reflect your changes at “^sip*”

(system) closed #28

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.