How to stop voice trafic from softphones

FreePBX Endpoints
41

Dicko,

If I use to add a notifier to send the complete list via email how can I achieve that

42

Just pipe the output through mail

(anycommandyouwant that generates an output on stdout)|mail -s "subject"  [email protected]

test it with

echo hello|mail -s "the result of  'echo hello' should be in the body of this email'  [email protected]
43

Have you tested it? It should be pretty obvious.

1 Like
44

Jerrm,

I’ll test it and update you.

45

How to get the output of this command via email

for ext in  $(rasterisk -x 'sip show peers'|egrep "^[0-9]*/[0-9]*.*OK"|sed 's/^\([0-9]*\).*/\1/');do echo -ne "$ext\t";rasterisk -x "sip show peer $ext"|grep Useragent|cut -d ":" -f2;done
46

That whole line is

(anycommandyouwant that generates an output on stdout)
47

just curious what’s your issue with them using non-standard phones?

in any case, would you not be able to enforce your WFH policy on the people themselves? you could easily catch them when they ask for support, or grep for UA like above

i feel communication in an org is key

1 Like
48

I feel this was a poorly rolled out and executed WFH policy. One that could have been completely avoided with the proper research and investment. Let’s look at the issue here, users are ending up on non-recommended softphone clients or cracked versions of commercial softphones. This is due to the fact that the users where given their SIP creds/details and then left to their own to download, install and program these clients. That was the first mistake.

Take away that something like Bria Teams or any other commercial softphone options that allows for mass user control/provisioning would have been the absolute right call for this, let’s look at what else could have happened. First, it seems there is a technical team as they are the ones that said “Use X softphhone”. THEY should have been the ones to take each phone, install the softphone, add the user details and set the phones up properly. The users should have never been given their SIP account details.

Basically the users were given the keys and told to pick the car they want. Even if it was strongly suggested they get X model, nothing was forcing them to. So now everyone is remote, no one can just stand over them or take their phone to install the proper software and the last two weeks have been spent on here trying to come up with some “solution” to block those people with bad softphone clients.

So the question I have now is Bob was given his SIP creds and told to download Zoiper. Bob decided to download Wink instead and use that. This solution will block the use of Wink, that’s great. What is Bob going to do now? Bob still needs to have a working phone but now doesn’t because the system is blocking his softphone, so now he needs to get Zoiper. Then there’s all sorts of good stuff like Bob going “Oh I lost my details, I need them again”. But either way Bob now needs to go and get the new softphone, install it and hope it works just fine. Which basically means the same process being repeated.

To tally this up, 2 weeks in and the solution still doesn’t work. Once it does that means each user that is blocked is a user that has to be contacted and dealt with to get them on the right softphone client and setup. This is arterial bleed level of cost and resources that totally could have been avoided with the right solution like Bria Teams (Bria is also offering 90 day licences due to COVID-19 and the WFH orders).

49

But this forum is always eager to rally together on an engineering solution for a stupid premise. :slight_smile:

5 Likes
50

If you want to have 5060 exposed, and you have a SIP attack AND the attacker forgot to change the user-agent info, then this might be useful. Lol.

51

True, but hindsight is 20/20 and a lot of folks had to rush to do things they never thought would be the case. Is it worth a 500 word essay?

1 Like
52

Guilty as charged, but I pull back once it starts to slide into spoon feeding.

1 Like
53

Yes. That’s why Post Mortem’s exist. To go over exactly what went wrong so it doesn’t happen again.

1 Like
54

By “this forum” I include myself as well; I just wasn’t in a hacking mood when the topic first came up. :smiley: spoon-feeding, no; Rube Goldberg bash scripts and unix pipelines, yes!

55

I count myself proudly in this group.

I appreciate this thread for the content, if not necessarily for end goal. I can imagine using the UA dialplan concepts for some future project, such as isolating a MAC address for emergency outgoing CID or something like that.

And @jerrm is right, there was a lot of track laid in front of the locomotive in response to the quarantine. Virtually none was implemented with any sort of planning. Our ticketing system has calmed down now, but for a few weeks it was just telephony whack-a-mole.

4 Likes
56

I was, and had been thinking about it anyway for TLS traffic.

For non-TLS traffic my firewall scripts require a valid ext@fqdn string and a valid useragent before asterisk sees the traffic. The combination drops all routine scans. Doesn’t mean a targeted attack couldn’t work it out, but all normal scanners have been dropped so far.

TLS scanning is orders of magnitude less common, this isn’t really needed, but adding it doesn’t hurt. Four lines of bash code added to my amportal.conf incrond script automates updating the UA regex using the same list maintained for the firewall, so it is zero extra maintenance.

It’s arguable how effective it will ever be, but it’s one more layer that does no harm, and may help at some point.

1 Like
57

Thanks Jerrm,

That’s really a cool thing you are doing.

58

Guys,

Actually the lockdown all happened so unplanned that we could not even find the time to setup every use independently.

so we gave the credentials to each user in the initial phase but after that when we achieve stability in first week of lockdown we switched to changing the passwords and setting up 10 to 20 users daily.

now there we see lot of users using cracked application to our exposed IP’s which is really a threat for us. so we come up with the idea to disable calling for all the users using cracked or non suggested applications.

we are not exposing default sip ports.

we are still looking if we can use any softphone which we can provision from Server automatically.

59

I think Zulu is probably one of the best solutions here, and clearly would be well supported by Sangoma, but maybe not your most economical solution.

60

I am currently using old PBX 2.11 and I don’t think so I can move to zulu but I have tested the Zulu on new PBX.

Is there any way that we can deploy free zulu type service ?