PIONEERS Played with Kamailio?

dicko

Still learning but earning
Joined
Oct 30, 2015
Messages
651
Reaction score
238
Consider this scenario,

DNS service providing SRV records to one or more machines

Vultr or vsp offering private network for traffic between instances

Dsiprouter at your donain.name routing and Sipproxying to your 10.n.n.n network

Lots of FusionPbxes (possibly on the same machine) connected to kamailio on 10.n.n.n

Phones registering to

[email protected]:55123
[email protected].domain.name:55123

. . . .
 
Last edited:

dicko

Still learning but earning
Joined
Oct 30, 2015
Messages
651
Reaction score
238
No, lots of small (or large) companies. The proxy is at domain.name. the pbxes at subdomains.domain.name as fusionbx domains, routed by dsiprouter as appropriate. But of course if you want domain1 domain2 then it would still work, that's just DNS (and SVR records for failover if desired) the point is to not use ip addresses or 5060 or its ilk ever, to easily accomplish failover and to do it all on as few machines as possible, thus not necessarily needing vpns r port knocking yet supporting clients in Chinese hotels, I suggest you keep your firewall but concentrate on port flooding and other kinds of ingress attacks, moving to TCP or TLS also improves security significantly

THeoretically you could do it all on just one machine.
 
Last edited:

wardmundy

Nerd Uno
Joined
Oct 12, 2007
Messages
15,154
Reaction score
2,632
Consider this scenario,

DNS service providing SRV records to one or more machines

Vultr or vsp offering private network for traffic between instances

Dsiprouter at your donain.name routing and Sipproxying to your 10.n.n.n network

Lots of FusionPbxes (possibly on the same machine) connected to kamailio on 10.n.n.n

Phones registering to

[email protected]:55123
[email protected].domain.name:55123

. . . .
This makes NeoRouter look better and better. Wouldn't have to expose your Asterisk server(s) to the public Internet at all.
 

dicko

Still learning but earning
Joined
Oct 30, 2015
Messages
651
Reaction score
238
Well Ward, if you go to that route then surely you need to have your clients install a neorouter client on every device be they Android, Windows, Linux, Apple,Router or hard phone needing acess to your services, Is that not onerous and prone to high "Customer Support" ?

I propose a solution that exposes only a very restricted access to only "fully qualified domain names" using a less used protocol over an unlikely port but to any raw Soft/hard phone that is cognoscente of these rules, no overreaching access blocking needed.

No Asterisk (or FreeSwitch) is ever exposed to the internet, all PBX voip traffic is on eth1 (10.n.n.n/n)

Watching sngrep on the dSIProuter has been very satisfying over the months watching the so far unsuccessful attempts slowly diminish.

You are of course subject to insider attempts, and some have actually been malicious. but that's another story.

Anyway, JM2CWAE and as you say it takes only an hour or so to get your feet wet.
 
Last edited:
  • Like
Reactions: wardmundy

ou812

Guru
Joined
Oct 18, 2007
Messages
462
Reaction score
70
I have a yealink phone pointing to the dsiprouter which is set as pass through to the asterisk server and the phone is registered on the asterisk server and can make calls, but when i call that extension "3000" it can not reach the yealink phone, with sngrep on the dsiprouter i see the invite but a 404 not found is returned, is there some special routing needed on the dsiprouter

I tried creating a DID 3000 pointing to endpoint that didn't work.

Gary.
 

dicko

Still learning but earning
Joined
Oct 30, 2015
Messages
651
Reaction score
238
It took me longer than a couple of hours to read all the support stuff for dSIProuter and how to actually configure it. I would start with getting a full-on real DID from a VSP to ring your Yealink.
 
  • Like
Reactions: wardmundy

wardmundy

Nerd Uno
Joined
Oct 12, 2007
Messages
15,154
Reaction score
2,632
Blocking Script Kiddies with dSIPRouter on CentOS 7

There's not much protection for dSIPRouter yet so we offer our tried-and-true iptables-restart for dSIPRouter. Just create the file in /usr/local/sbin and make it executable. Then run it whenever firewalld is restarted. We'll post updated creep lists here periodically to keep you safe.
Last updated: 1/23/2019 7:40 am EST

Code:
#!/bin/bash

firewall-cmd --complete-reload
wait
sleep 5

# script kiddies

iptables -I IN_public -s 37.48.0.0/12    -j DROP
iptables -I IN_public -s 51.38.54.53     -j DROP
iptables -I IN_public -s 51.75.130.176   -j DROP
iptables -I IN_public -s 96.4.166.79     -j DROP
iptables -I IN_public -s 109.110.38.6    -j DROP
iptables -I IN_public -s 118.38.198.68   -j DROP
iptables -I IN_public -s 147.135.64.0/24 -j DROP
iptables -I IN_public -s 159.65.146.195  -j DROP
iptables -I IN_public -s 163.172.64.18   -j DROP
iptables -I IN_public -s 176.32.32.76    -j DROP
iptables -I IN_public -s 185.53.88.0/22  -j DROP
iptables -I IN_public -s 185.107.94.36   -j DROP
iptables -I IN_public -s 188.165.222.1   -j DROP
iptables -I IN_public -s 194.63.140.172  -j DROP
iptables -I IN_public -s 216.244.65.186  -j DROP
iptables -I IN_public -s 217.145.239.40  -j DROP
iptables -I IN_public -s 5.250.136.139   -j DROP
iptables -I IN_public -s 46.17.47.130    -j DROP
iptables -I IN_public -s 104.248.184.50  -j DROP
iptables -I IN_public -s 118.70.213.14   -j DROP
iptables -I IN_public -s 142.4.23.107    -j DROP
iptables -I IN_public -s 142.4.25.230    -j DROP
iptables -I IN_public -s 178.211.51.210  -j DROP
iptables -I IN_public -s 178.211.51.213  -j DROP
iptables -I IN_public -s 185.245.84.22   -j DROP
iptables -I IN_public -s 188.168.81.191  -j DROP
iptables -I IN_public -s 207.99.5.122    -j DROP
iptables -I IN_public -s 212.129.36.27   -j DROP
iptables -I IN_public -s 159.65.146.195  -j DROP
iptables -I IN_public -s 217.145.239.40  -j DROP
iptables -I IN_public -s 96.4.166.79     -j DROP
iptables -I IN_public -s 176.32.32.76    -j DROP
iptables -I IN_public -s 5.250.136.139   -j DROP
iptables -I IN_public -s 45.119.83.187   -j DROP
iptables -I IN_public -s 46.17.47.130    -j DROP
iptables -I IN_public -s 58.181.246.63   -j DROP
iptables -I IN_public -s 104.248.184.50  -j DROP
iptables -I IN_public -s 118.70.213.14   -j DROP
iptables -I IN_public -s 142.4.23.107    -j DROP
iptables -I IN_public -s 142.4.25.230    -j DROP
iptables -I IN_public -s 178.211.51.210  -j DROP
iptables -I IN_public -s 178.211.51.213  -j DROP
iptables -I IN_public -s 185.40.4.67     -j DROP
iptables -I IN_public -s 185.245.84.22   -j DROP
iptables -I IN_public -s 188.168.81.191  -j DROP
iptables -I IN_public -s 207.99.5.122    -j DROP
iptables -I IN_public -s 212.129.36.27   -j DROP
iptables -I IN_public -s 45.119.83.187   -j DROP
iptables -I IN_public -s 58.181.246.63   -j DROP
iptables -I IN_public -s 185.40.4.67     -j DROP
iptables -I IN_public -s 192.162.101.242 -j DROP
iptables -I IN_public -s 62.4.15.23      -j DROP
iptables -I IN_public -s 81.7.10.253     -j DROP
iptables -I IN_public -s 62.210.89.0/24  -j DROP
iptables -I IN_public -s 185.107.94.0/24 -j DROP
iptables -I IN_public -s 185.53.91.0/24  -j DROP
iptables -I IN_public -s 212.129.28.190  -j DROP
iptables -I IN_public -s 209.197.191.71  -j DROP
iptables -I IN_public -s 52.183.36.191   -j DROP
iptables -I IN_public -s 62.210.87.182   -j DROP
iptables -I IN_public -s 46.29.162.94    -j DROP
iptables -I IN_public -s 190.24.116.15   -j DROP
iptables -I IN_public -s 194.147.32.109  -j DROP
iptables -I IN_public -s 190.24.116.15   -j DROP
iptables -I IN_public -s 194.147.32.109  -j DROP
iptables -I IN_public -s 212.129.3.61    -j DROP
iptables -I IN_public -s 185.107.83.44   -j DROP
iptables -I IN_public -s 88.212.208.37   -j DROP
iptables -I IN_public -s 212.83.145.185  -j DROP
iptables -I IN_public -s 145.239.29.252  -j DROP
iptables -I IN_public -s 147.135.39.29   -j DROP
iptables -I IN_public -s 142.4.28.190    -j DROP
iptables -I IN_public -s 209.126.105.174 -j DROP
The other things I would do are (1) add #!define WITH_ANTIFLOOD just after the UAC entry in the top section of /usr/src/dsiprouter/kamailio/kamailio51_dsiprouter.cfg and (2) search for "friendly" and insert the following
Fred Posner code from Astricon just above that line. I also like to bump up the ban time from the default 5 minutes in the
----- htable params ----- code section. Then execute: service dsiprouter restart.

Code:
### Fred Posner additions
        if ($ua =~ "(friendly-scanner|sipvicious|sipcli)") {
                xlog("L_INFO","script kiddies from IP:$si:$sp - $ua \n");
$sht(ipban=>$si) = 1;
                sl_send_reply("200", "OK");
                exit;
        }
    if($au =~ "(\=)|(\-\-)|(')|(\#)|(\%27)|(\%24)" and $au != $null) {
                xlog("L_INFO","[R-REQINIT:$ci] sql injection from IP:$si:$sp - $au \n");
$sht(ipban=>$si) = 1;
                exit;
        }
###
 
Last edited:

wardmundy

Nerd Uno
Joined
Oct 12, 2007
Messages
15,154
Reaction score
2,632
I have a yealink phone pointing to the dsiprouter which is set as pass through to the asterisk server and the phone is registered on the asterisk server and can make calls, but when i call that extension "3000" it can not reach the yealink phone, with sngrep on the dsiprouter i see the invite but a 404 not found is returned, is there some special routing needed on the dsiprouter

I tried creating a DID 3000 pointing to endpoint that didn't work.

Gary.
Assuming you set the phone up following the last use case here, I have confirmed your observation that incoming calls always get sent to voicemail if you register on the Kamailio server. I think it's a bug. The Asterisk setup that works for us is to register the phone directly with the Asterisk server. I'm hoping @dicko will come join the party since he has a PhD in SIP.
 
Last edited:

wardmundy

Nerd Uno
Joined
Oct 12, 2007
Messages
15,154
Reaction score
2,632
Incoming SIP URI Calls That Work

Having done some experimentation, here's what works with incoming SIP URI calls to your dSIPRouter's FQDN...

First, if you're using Incredible PBX as your pass through Asterisk server, you still must WhiteList the IP address of the SIP URI caller even if the calls are directed to your Kamailio server's FQDN. Otherwise, incoming calls will ring with no answer ever. If you open UDP 5060 on your Incredible PBX server, this would change so that calls enumerated below would work for everybody, BUT your server would be exposed to the entire Internet for anonymous SIP calling and attempts to hack into your server's extensions and trunks. Not recommended! We had hoped that the dSIPRouter setup would allow anonymous SIP calls to the FQDN of your Kamailio server without having to open up UDP 5060 on your Asterisk server, but that is NOT the case.

Second, the from-trunk context setting in your Kamailio trunk setup on Incredible PBX means (1) SIP URI calls to all extensions will work and (2) SIP URI calls to DIDs enumerated in your inbound routes will work. All other calls will be processed by the Default Inbound Route which we recommend setting to Terminate Call: Play no service message. Since your firewall is blocking anonymous SIP URI calls, the other option is to change the from-trunk setting to from-internal which would mean that those whitelisted in IPtables could actually make outbound calls through your PBX using SIP URIs and your outbound routing rules, e.g. [email protected]. Of course, if your firewall ever goes down, U R screwed. The whole world could make calls on your nickel. Hence, not recommended.
 

wardmundy

Nerd Uno
Joined
Oct 12, 2007
Messages
15,154
Reaction score
2,632
Well Ward, if you go to that route then surely you need to have your clients install a neorouter client on every device be they Android, Windows, Linux, Apple,Router or hard phone needing acess to your services, Is that not onerous and prone to high "Customer Support" ?
What I had hoped to do was have SIP endpoints register to the dSIPRouter and have all calls processed there so that the Asterisk server's SIP ports could be hidden. Unfortunately, we hit a wrinkle as documented in the first paragraph above.
 

dicko

Still learning but earning
Joined
Oct 30, 2015
Messages
651
Reaction score
238
Incoming SIP URI Calls That Work

Having done some experimentation, here's what works with incoming SIP URI calls to your dSIPRouter's FQDN...

First, if you're using Incredible PBX as your pass through Asterisk server, you still must WhiteList the IP address of the SIP URI caller even if the calls are directed to your Kamailio server's FQDN. Otherwise, incoming calls will ring with no answer ever. If you open UDP 5060 on your Incredible PBX server, this would change so that calls enumerated below would work for everybody, BUT your server would be exposed to the entire Internet for anonymous SIP calling and attempts to hack into your server's extensions and trunks. Not recommended! We had hoped that the dSIPRouter setup would allow anonymous SIP calls to the FQDN of your Kamailio server without having to open up UDP 5060 on your Asterisk server, but that is NOT the case.

Second, the from-trunk context setting in your Kamailio trunk setup on Incredible PBX means (1) SIP URI calls to all extensions will work and (2) SIP URI calls to DIDs enumerated in your inbound routes will work. All other calls will be processed by the Default Inbound Route which we recommend setting to Terminate Call: Play no service message. Since your firewall is blocking anonymous SIP URI calls, the other option is to change the from-trunk setting to from-internal which would mean that those whitelisted in IPtables could actually make outbound calls through your PBX using SIP URIs and your outbound routing rules, e.g. [email protected]. Of course, if your firewall ever goes down, U R screwed. The whole world could make calls on your nickel. Hence, not recommended.


While I don't really use asterisk with dsiprouter (fusionpbx has much better integration) have you considered adding

domain=your.fully.qualified.name
domain=127.0.0.1 ; if you have a need

To /etc/asterisk/sip_general_custom.conf

It would restrict registration and thus outgoing calls to extensions on these 'local domains' and is similar to only using domain names with fusionobx and deleting the IP named one.

I also suggest you use TCP transport connections on a unlikely port also
 
Last edited:

ou812

Guru
Joined
Oct 18, 2007
Messages
462
Reaction score
70
While I don't really use asterisk with dsiprouter (fusionpbx has much better integration) have you considered adding

domain=your.fully.qualified.name
domain=127.0.0.1 ; if you have a need

To /etc/asterisk/sip_general_custom.conf

It would restrict registration and thus outgoing calls to extensions on these 'local domains' and is similar to only using domain names with fusionobx and deleting the IP named one.

I also suggest you use TCP transport connections on a unlikely port also
I use that setting on all my asterisk servers, but I still can not route incoming did's to it, I also tried routing to a yealink phone that is registered directly to dsiprouter with no asterisk involved and it also does not work, there must be a lot more to the routing than simply using the gui option "inbound did mapping". still reading a lot of post but with out success, any hints on what I should be looking for, is there a module that needs to loaded.

Thanks,
 

ou812

Guru
Joined
Oct 18, 2007
Messages
462
Reaction score
70
I'm finding that the use of domain names instead of ip address's is causing some issue's, I could not route DID's to end points registered to dsiprouter if the carrier was connected using domain name, once switched to ip it works, some thing for routing DID's to Asterisk pbx, the pbx needs to be set with ip address and routing works, now to just find out why pbx can't call end point.

Gary.
 
  • Like
Reactions: wardmundy

dicko

Still learning but earning
Joined
Oct 30, 2015
Messages
651
Reaction score
238
Do you have the convenience to try the same scenario with FusionPBX?
 

ou812

Guru
Joined
Oct 18, 2007
Messages
462
Reaction score
70
I setup a FusionPBX server about 6 months ago and it worked great except for the blf buttons, I was quite unhappy with the problems with these buttons, if I remember correct it was things like they didn't light when server side dnd was used, you needed 2 buttons for a acd agent to login/out and show status of that condition, overall the system was good but searching through forums blf's seem to be a issue, it may of been my lack of knowledge with Fusionpbx or perhaps these things are now fixed. does your experience with fusionpbx have the same issue. And yes I can setup a Fusionpbx server for testing with Dsiprouter.
 
  • Like
Reactions: wardmundy

dicko

Still learning but earning
Joined
Oct 30, 2015
Messages
651
Reaction score
238
I cant disagree necessarily , my use case has been to replace lterally dozens of 3 to 20 seat small pbx's running under freepbx on 5 dollar a month machines into two 5 dollar a month fusionpbx machines running mostly redundant. Not perfect yet but certainly better than before (and further with painless faxing) . All use domain names, all use tcp/344553;-) nothing has been compromised or even snooped past one packet in months.

I just offered it for consideration, I am definately not an authority nor do I want to be :)

As an afterword, I find Siremis on straight kamailio less functional. JM2CWAE
 
Last edited:
  • Like
Reactions: wardmundy

wardmundy

Nerd Uno
Joined
Oct 12, 2007
Messages
15,154
Reaction score
2,632
Agree on Siremis. More trouble than it's worth. And FusionPBX remains one of our favorites although there's a carryover of some of the mentality from the early Asterisk days where documentation was all but hidden in order to generate revenue for consultants and paid training programs. Here are some Nerd Vittles tutorials to get you started for those that just want to try things out.
 
Last edited:

Members online

PIAF 5 - Powered by 3CX

Forum statistics

Threads
22,375
Messages
137,424
Members
14,578
Latest member
BoRoDKuH