Ring Central Security

  • 1
  • 1
  • Question
  • Updated 2 years ago
  • Answered
I run sniffing software to see if there is any unaccounted for network traffic.  With Ring Central desktop for a softphone running, I observe over an 8-hour period hundreds of IP connections from all kinds of countries where I have no Ring Central contacts (I only have a few in the USA).  These include China, Russia, Hong Kong, Malaysia, Egypt, etc., etc.  I assume that in order for one RC desktop client software anywhere in the world to know the status of another RC client anywhere else in the world, it must know it's public facing address and use the well-known and published listening port for that RC listening-port softphone app.  Thus my desktop behind my firewall should be under constant (albeit throttled to prevent DDOS) attack(s) from such messaging and I assume this is why I see over 800 messages from around the world when RC is running.  When I exit RC for desktop, there is no such activity.

I am surprised there is no discussion about this in the Security and network Configuration guides since after all, this is always the consequence of any application with a listening port unless you do Network Address Translation but since each desktop client has it's own unique listening port then all hackers need to do is try say 1/2 dozen or so of those well-known listening ports after doing port scans to determine that IP is listening.  Then they can send messages at a rate that doesn't draw the attention of the firewall.  And noone wants to be in the blacklisting business for IP addresses as this is an endless task.  And white listing can also be problematic and a maintenance nightmare -- do you really know where all calls are going to be coming from?  If you have the Office product and calls are being recorded, then I am assuming it would be appropriate to use whitelisting by providing a safe set of well-known IP (or IP ranges) published by RC and which act as proxies to record the call.  That makes sense but I had to figure *ALL* this out by myself from several phone calls and experiments about how the Office (paid) version works vs. how do hackers trying to use RC for free calls to each other works.  And I had to pause and ask, if hackers are trying to look for vulnerabilities in the RC protocol, of what benefit would this be?

A good tech-note along these lines showing why firewalls should only permit traffic from RC servers to those well-known RC listening port would be very useful but instead they are small bullet points in a large document without painting the overarching picture.  In truth, many small businesses do not even understand firewalls and the need to do this and why.

Thanks,

Harry
Photo of harry

harry

  • 140 Points 100 badge 2x thumb

Posted 2 years ago

  • 1
  • 1
Photo of Brandon

Brandon, Champion

  • 19,914 Points 10k badge 2x thumb
There is actually no requirement or reason to open your stateful firewall to any unsolicited inbound traffic with RingCentral and you never should.  I suspect the messages you are seeing are because of the wide variety of services RC uses around the world to support things like webRTC, messaging, voice, etc.  This is quite normal for these types of real time communications products.  Here are some references to help get a better understanding of how your network should be configured and why:

https://netstorage.ringcentral.com/guides/network_condensed.pdf

https://netstorage.ringcentral.com/guides/network_extended.pdf

Try looking at the traffic with apps like WebEx, Skype, Facebook messenger, etc. and I suspect you will see similar traffic patterns if you are interested.
(Edited)
Photo of Mike

Mike, Official Rep

  • 91,622 Points 50k badge 2x thumb
Thanks for your post Harry, 

Just to let you know, the links Brandon posted above should always contain the most recent Network Configuration requirements.  I've forwarded your post to be reviewed and I'll see if we can't get some sort of explanation or update added to the Expanded version.  

Thanks!
Mike
(Edited)
Photo of harry

harry

  • 140 Points 100 badge 2x thumb
Hi guys,

I looked at the condensed version and it is very professional but trust me, it is very confusing except for the senior network engineer at Ring Central.  For an experienced Windows operating systems, network, and security expert (self-proclaimed) I have to parse the words in the condensed version several times to draw the following conclusions.
(1) Brandon points out the quote about stateful firewalls from the condensed PDF but all this is saying is that from the point of view of inside the LAN (with the firewall between the LAN and the WAN), any UDP message going out to the WAN will be responded to by it's intended target and the state of the UDP connection will be maintained, as though it were TCP, and that the intended party and only the intended party (which could be your server as well) will respond to receive the message.  That is all very uninteresting to me because that is how I expect traffic I initiate inside my firewall to work.
(2) the concern I was expressing was from traffic generated *outside* the firewall such as people trying to fake and behave like your servers do by reverse engineering your registration protocol.  when this traffic comes in to the firewall which has no Access Control Lists, such as I claim most of your small business customers do not (but should), it *will* reach it's intended port listening (on a Windows listening socket) for registration of an incoming phone call.  They will be handed a socket for the audio from the ephemeral range you document and this is what I see from all over the world (mostly countries associated with hacking). 

It took a lot of work to understand that this can be stopped by setting up the ACL for the inbound-to-the-LAN phone calls.  Your documents do a good job but should emphasize the "life cycle of a call coming into your LAN" and show how this unnecessary traffic can be problematic to a workstation and deserves to be stopped at the firewall via ACL configuration.

Make sense?

Harry
(Edited)
Photo of Brandon

Brandon, Champion

  • 19,914 Points 10k badge 2x thumb
This is a good conversation, but I think there is still some essential misunderstanding here.  Your point #2 seems impossible because the phones are provisioned to register with RingCentral.  With the exception of some *very* sophisticated type of man in the middle attack or DNS hijack allowing someone to load a malicious provisioning file to your phones (that you have no reasonable way to protect yourself against with your firewall anyway) the phones will only try to communicate with RingCentral.  Certainly for SoftPhones this is even less of an issue.  ACL's or not, no outside parties can see, much less attack internal resources.

Basically, unless you open ports on your firewall, no outside attackers can see much less attack any internal resources.  I actually disagree with the way the inbound ACL's are presented in the doc because they don't make clear that you would only need to use them in special circumstances.  Think about implementing them for a moment.  If you configure your firewall to only accept inbound traffic from those IP addresses.  Nothing, but RingCentral will work through that firewall :)

As for outbound, RingCentral acts no different then any other communications application.  You could implement outbound ACL's to ensure SIP and provisioning traffic only communicates to listed RC servers if paranoid I suppose, but it seems unnecessary.

Now, what I consider to be the biggest potential vulnerability would be someone gaining access to your admin account.  This would allow some obvious harm and possibly allow an attacker to gather registration info and configure their own endpoints to make and receive calls on your account.  This is handled pretty well with 2FA RC uses to confirm identity.  In fact, many people complain about how you may have to answer security questions to reset a password or reconfirm with 2FA every time accessing from another browser or computer.
Photo of harry

harry

  • 140 Points 100 badge 2x thumb
I agree there is misunderstanding :-).  First (or second) ACLs can be set up so that traffic inbound on the registration ports 5060-6000 is only allowed when it comes from your servers.  Everything else would work just fine.  This would stop others from faking the registration protocol which comes back to point number one, they don't need to make a real phones to me through your server -- they can mimic what your server does when your server receives a real phone call intended for me and initiates the registration as your server to my firewall to my-desktop-inside-LAN-  They can do this so long as my firewall permits it to come in from ANYWHERE, which it does without any ACLs.  The next-to-last bullet in the condenses document/pdf states this as (to me) the single most important point in the document:when it says

For inbound traffic, the ACL must be set to the following RingCentral originating source IP address ranges:104.245.56.0/21, 185.23.248.0/22, 199.68.212.0/22, 199.255.120.0/22, 103.44.68.0/24

It is referring to an ACL restricting the inbound ports such as the registration ports for a softphone (5060-6000) or any of the ports shown in the table for inbound.  I apologize in advance if we are still not understanding each other.  This can be confusing stuff.  Perhaps you have a better understanding of networking in this instance than I do but I stand firm on my points.

Harry
Photo of Brandon

Brandon, Champion

  • 19,914 Points 10k badge 2x thumb
Yes, I concede you are correct about the fact ACLs can be configured that way. This is part of why I don't like how they are presented in the doc.  The information provided does not explain anything about reflexive ACL's or link to anything about them or how to use them as they are describing.  If one simply tried applying them as stated in the doc they wouldn't work as expected and probably break a lot of things.

Do you have any examples or evidence of this type of attack it would help prevent against?  It seems you are aware of concerned about a particular, potential vulnerability.  Most voip vulnerabilities I am familiar with are based around attacking open servers.  I would be curious to learn how thee type of attack you are describing might even be possible.
Photo of harry

harry

  • 140 Points 100 badge 2x thumb
By definition, any desktop behind a firewall without ACL and listening on any listening port is an "open sever". i use smsniff and ipnetinfo by nirsoft -- i run smsniff for a few hours and then stop it, select all the rows and right-click and send to ipnetinfo who does the whois and shows me the company name and country.  I see maybe 100 Norton, Microsoft, Skype, Dropbox and Amazon (aws servers) connections in 8 hours. When I run Ring Central Softphone for 8 hours I see over 900 connections and their country's of origin are all over the place.  These folks are doing port scans on my public-facing IP and seeing those ports 5060-6000 open and are sending TCP messages to see what response they get.  They are simulating your server (if you work for RC).  I have seen this on several desktops running RingCentral.  The amount of traffic depends on what value the hackers see in the IP address.  If it's a home desktop, there is a few attempts (less than 10) in eight hours.  If it's a corporation, I see hundreds.  This is normal of course. 

But customers should aggressively stop this crap at the firewall level.  The Windows firewall can also be used to stop it but it can't do it as well as a good firewall (iIt can't block it by IP as far as I recall).  Some Windows firewall software adjuncts (Kaspersky, Norton?, McAfee) etc. act like hardware firewalls and can intercept all network traffic and perhaps do what the hardware firewalls do with ACLs but this is also too challenging for most small business users.

Thanks and try out smsniff and ipnetinfo.  Your AV will complain about smsniff but it's a false positive.

http://www.nirsoft.net/utils/smsniff.html
http://www.nirsoft.net/utils/ipnetinfo.html

Of course the inbound traffic is never a flood because even the worst hardware firewall will default to doing basic throttling to prevent flooding from denial-of-service attacks.

What the hackers are looking for is to reverse engineer the registration protocol and then find vulnerabilities to penetrate the machine.  Trust me, the hackers have been doing this to software with listening ports for many years and the software and protocols they target are very secure.  But the bad guys, unfortunately, are always 1/2 to 2 steps ahead of the good guys.  The goal is to keep it down to 1/2 step and reduce the risks that way.
Photo of John Tran

John Tran, QoS Network Analyst

  • 350 Points 250 badge 2x thumb
Hi Harry/Brandon.  

Thanks for the lively discussion on the matter.  Aside from any specific/technical configuration settings relating to the ACL and such that are not covered in the documentation, our overall goal on that was to more or less provide general config sample(s) to back up the specifics of what RingCentral-related ports/destination subnets the phones need to connect to.  Because we cannot cover all (or assume for all) customer network/firewall setup scenarios, we leave it up to each customer to implement their firewall needs beyond these RingCentral-specific requirements (operating ports to subnets).  We will have our documentation team review the mentioned sample ACL config where statements may be out of order in terms of the logic/execution.  Again, beyond the scope of allowing the specific RingCentral ports-to-subnet(s) traffic, in/out of the Network, it is usually up to the customer to secure their network entirely.  On the RingCentral end, we do have counter-measures as appropriate.

As for your initial statement, "I assume that in order for one RC desktop client software anywhere in the world to know the status of another RC client anywhere else in the world, it must know it's public facing address and use the well-known and published listening port for that RC listening-port softphone app"  ...that is somewhat true, however it is something that is only known/handled by our servers, and should not be propagated beyond (i.e. to a phone that's sitting idle).  If the IP's you see in your initial sniffer-capture are evident as coming from RingCentral please do open a case (along with the sample capture) so that our Product/Security team can further review.  Thanks again, for bringing up the concerns.

-John