StarBox Security FAQ’s

StarBox Security FAQ’s

Q: How does the StarBox authenticate with the call center or the remote station in which it communicates?

A: All administrative traffic from Star2Star's Constellation Network to the StarBox Cloud Connection Manager appliance is done via Secure Shell / SCP.

Q:  Does it use mutual authentication and is the authentication hardware token or soft cert based?

A: We use software certificates. When Star2Star provisions a site we automatically generate a 2048-bit x.509 certificate for the site's StarBox appliance.

Q: Is the channel encrypted in some manner?

A: Administrative traffic such as updates to underlying config files are encrypted, however voice communication is not.

Q: I realize the StarBox pulls voice packets out of the data stream, but it is still connected to our network. Are there measures within the StarBox to prevent dual homing so that an attacker cannot gain access to the network?

A: Customers who run a converged LAN, (i.e. with each workstation connecting to the PC port on the IP phone) have their traffic segregated with VLAN's. Star2Star uses static VLAN Assignments as opposed to CDP or LLDP and all IP phones ship configured to use a voice VLAN of 41 and to get DHCP from the StarBox's sub interface on that VLAN. That setup is adequate for most organizations, however it's certainly true that a malicious user could configure their network card to run on that VLAN and follow the same path as the IP phones. That would require knowledge of the voice VLAN, a dot1q-enabled NIC, and admin rights on the workstation.

Most customers we work with are comfortable with VLAN segregation as being adequate, although we have some who for regulatory or administrative reasons run separate physical networks. We do also have an enterprise customer with an 802.1x authentication, where the organization's Radius server assigns a voice VLAN attribute based on the certificate that's presented by the phone. We could certainly discuss such a setup, but going down the dot1x rabbit hole is not exactly a trivial setup.

Q: Regarding upgrades to the StarBox and phones (software, firmware, etc.), are the updates stored or loaded onto the StarBox and then installed or pushed to the handsets? If not, how do updates get installed on all hardware?

A: That's exactly how Star2Star manages endpoint firmware and configs. It's a push from our provisioning servers in Constellation to the StarBox, and a pull from the phones to the StarBox. We are also dabbling with cloud storage in some isolated firmware cases, but the majority of endpoint firmware files and config files are stored on the StarBox Cloud Connection Manager appliance and served from the StarBox via TFTP and HTTP over the voice VLAN.

Q: Can we expect to reach a point to where the system or hardware reaches an end of life situation such that upgrades will be mandatory. If so, what happens then?

A: The StarBox appliance is both managed and supported by Star2Star. There's never a point where we would force a customer to upgrade, although a customer who eventually grows beyond the capacity of their current appliance would want to consider an upgrade. For reference, the device capacities are 20 extensions and 10 concurrent calls for our smallest device, 250/50 for our mid-range appliance, and 500/100 for our largest one. The hardware is specified to have a 7-year lifespan, but the majority of appliances we fielded seven years ago are still in service. Next-day hardware replacement is covered under maintenance for any type of failure including fire, electricity, acts of God etc., but there has never been a point where a StarBox has been RMA'd for an actual hardware failure on its own. We certainly have RMA'd devices to rule out a hardware problem, but when we've tested such devices we've found the hardware to be sound.







Article is closed for comments.
Powered by Zendesk