Best options to secure webrtc

What is the best options to secure webrtc?

I’m getting ready to expose my asterisk server to the work as part of project. Previouly i have had to have users in VPN sessions to gain a pjsip session.

Now its full on webrtc. I have a ingate separator that I have put infront of this. any recommendations. The Separator sits on the internet on one interface and one on the local network where my asterisk servers are.

Very open ended question… so… while i’m not familiar with the Ingate products, its probably some SIP Voip solution - like an SBC.

You may need to do your own research on how this SBC can terminate webrtc connections (if it can). Remember that WebRTC uses a TCP connection - not UDP (like traditional Voip SIP). TCP is also stateful, and the connection will (should) be established using TLS (most browsers don’t support ws: for media any more).

These are massive differences in terms of networking… The initial connection that your websocket connection will establish should be limited to TLS only, and so be inherently secure, but there are a number of things you need to consider with that initial connection;

Will that connection be forwarded in directly to the Asterisk box (to the mini http service), or will you terminate before and reverse proxy back to the Asterisk box? I can tell you now, the Asterisk mini HTTP service is simply not built for mass connections, and will fail quickly especially under a DOS attack.

If you terminate before hand, what will you use - does the Ingate offer this? not sure… find out. If it does what are the connection limits there… what TLS versions does it offer, what certificates can you load on it? Will you use Self-Signed certificates? All questions you need to find out.

Either way… ok, now you have a LTS connection from a websocket client to Asterisk (or proxy), and SIP packets can flow between them… now you need to consider your password policy… are you going to use passwords? or is it IP auth? IP auth is more secure, but a massive hassle because IPs can change easily, and especially if you allow connections from the greater internet, their ISP may change the IP address mid session… so you use username-password auth… what username policy do you apply? what password policy do you apply? how do you communicate the password to users… do you bang them off and email?

These questions and many more are endless, and some are food for thought… but all form part of security. Good luck :slight_smile:

1 Like

I can auth the users web session and have strong passwords, etc, . I Wish there was a way to make asterisk stronger such as mfa or something. I hate having something as simple as a static password, add in mfa or other 2nd factor and the game gets much harder.

You can implement multi-factor authentication in the dialplan, itself.

You can also use TLS client certificates in combination with a password, although arguably that is a form of compound single factor authentication.

You can do IP plus password.

There are a number of ways to secure Asterisk once you have secured the actual server on the OS level.

In the public space (cloud/hosted), you are best with IP auth… although personally I prefer IP “allow”, with Digest auth… in other words, “Provide both an auth, and come from an allowed IP, and you’re in.”. This way even if the username and passwords get compromised, you would have to be hacking from the same network.

But let’s say however that this was somehow achieve by a potential intruder… remember that the most common objective would be for someone to dial a number in a foreign country using one of those high rated call costs, that they get a split of the inbound fee… money right… its about money!

So make sure your dial plan is locked down. Avoid doing thing like:

exten => _.,n,Dial(PJSIP/${EXTEN}@twilio-trunk,30)

You are literally asking for trouble here. If an extension SIP details are somehow compromised, an extension could potentially dial any number in the WORLD!

Get your staff/clients to enter a pin or just something, so that you know they are able to dial the destinations they want. I’m not suggesting on all numbers, probably only on international.

Another thing, make sure the extensions, can only make 2 or 3 simultaneous calls at a time… a human could hardly manage more than 3 outbound calls at a time… i mean take it easy right… finish calling your mom, and then call your buddy… right?

The hackers are going to launch as many simultaneous calls as they can, so by slowing that all down to seriously limit the impact a breach could have.

Then finally, though it takes quite a bit of post processing, use a log analyser to check the logs of incorrect username and passwords. If a hacker/bot is poking around on your server, you should see many many auth failures, they normally go… 100, 101, 102, 103… etc etc

Good luck, Asterisk security is a big topic!

I think I’ve got it limited to 1 call call at a time so that will help.

Is there some example code on force an auth dial plan? How would one do a MFA auth at registration? I could see doing something funky on dial plan out bound I guess with a agi script but jeeeze this would be bad on call center staff.

If it was on registration it would be more acceptable.

What I have seen before is like a “client login”, so basically the SIP details are meaningless and arbitrary, but also not connected to any outbound routes, then when a call center agent gets to work, they have to “login”, this activates routes, say in the db, or some variable is set etc. The login could be some simple CRM/ERP system/site/page or some PIN the agent applies using the keypad. This way you completely take SIP details out of the security equation and rely on CRM/ERP to do the job. (The CRM could even have MFA). Your only task there is session management, when does it expire, do they have to “log off” etc etc.

I think you misunderstand the purpose of registration. It is not primarily about authentication, but rather about telling the PABX where to send outgoing calls. Authentication mechanism are limited by SIP. However, you can still restrict by IP address, password, and client certificate.

SIP doesn’t require you to be registered to make a call, even if is common to authenticate INVITEs against the source address of the registration. (This is one reason why type=friend is a bad idea on chan_sip. I’m assuming that WebRTC doesn’t impose a requirement to register first.

Yes, its registration events but for calling out you still have to Auth with your creds. Its not a registration but the first packet will be deny followed by the auth.

In any case this is were more validation is good. There must be someone that has an example of something that tightens up security on this out there. After all I’m not the only one concerned I’m sure.

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