Network Attack Resolved

Chinese attempt at brute force attack foiled.

On Saturday November 11th, 2018 at 04:30 EST SoniXCast was contacted by the United States Federal Bureau of Investigation that there was a brute force attack occurring on the SoniXCast edge network that serves US government systems. Within a short period of time the attack expanded to other SoniXCast networks in Canada and Europe that serve federal and commercial services including retail branch services.

The attack was mounted from the US.

The attack was mounted from 3 separate US location from Virtual Private Servers located in Atlanta Georgia, Dallas Texas and San Francisco California. Payment came from an offshore financial services company known to be associated with Chinese Intelligence Services. The attack was in form of a bot that would attempt multiple password variations in order to gain root access to a system. By evaluating TCP headers, technicians were able to backtrack connections to a server in Taiwan China.

The Resolution

SoniXCast emergency attack protocol was immediately implemented which confuses most modern network attacks. However, the protocol also confuses customer systems so some minimal downtime was experienced. There seems to have been a timeout associated with the attack script so that when the requested ip-address and port was no longer available, the bot gave up and moved on to another system which minimized downtime overall.

SoniXCast is cooperating with the US federal government and has contacted cyber attack units in countries where the attack on SoniXCast networks occured. Once a full report has been issued, the network team will evaluate and advise if further actions are necessary.

BB38 Update

BB38 has reached minimum thresholds.

The master server image for BB38.sonixcast.com has been moved to a new dedicated hardware primarily to allow for more resources for customers, but also to ensure for adequate resources are available for future customer sign-ups.

BB38 has been running in ‘hot-swap’ (switching between dedicated hardware) mode for the last 72 hours due to high loads and the decision has been made in order to eliminate any possible downtime to upgrade the backing hardware.

BB38 will run redundantly (all images running simultaneously) for the next 24 hours in order to allow adequate time for proper worldwide ip-address replication before taking the old images offline.

Customer Impact

IP-Addresses will change, however these changes will be reflected in our worldwide DNS and AnyCastIP nodes and no customer impact is expected. Customers are however encouraged to double check any file uploads made within the last 72 hours to ensure that they were properly replicated during the upgrade process.

More upgrades in the works

BB34.sonixcast.com and cc.sonixcast.com images are very close to reaching minimum resource allotment and will be similarly upgraded to new hardware over the next days or weeks. In each case an announcement will be made separately.

CABHSxx Retired. Use BBxx Instead

Don’t use CABHSxx anymore. Use BBxx instead.

As announced in July 2017, we were required to update our server naming conventions from ‘cabhsxx.sonixcast.com’ to ‘bbxx.sonixcast.com’ and have finally retired the cabhsxx hostname alias.

Why the Change?

The naming convention cabhsxx is used by OVH Canada in naming their router network and early last year they requested that we change our hostnames. In the spirit of conscientious partnership (OVH Canada is a primary provider of hardware services for SoniXCast), our management team decided to comply, however it was communicated that a certain migration period would be required. Later on in the year, our license provider required that we associate host naming conventions with our broadcast call signs. Since we were going to have to change hostnames anyways, we decided on the ‘bbxx’ (for BoomBox) hostname prefix.

Unlike other providers, SoniXCast’s core business revolves around terrestrial radio, media content aggregation and popularization. Demands within the industry require that we adhere to strict guidelines which includes the propagation of associative and intuitive naming conventions.

As such, both partners and customers required that we upgrade our naming conventions to comply with local licensing regulations which we begun implementing in July 2017. In November, 2018 we officially retired the cabhsxx hostname prefix and removed it from our DNS servers.

Who or What is affected?

All SoniXCast customers were notified immediately last year in July 2017 as well as in regular quarterly newsletters that the pending host naming conventions would be changing. On November 5th, 2018 we received a letter from our license provider demanding the retirement of the cabhsxx prefix from our DNS servers and our management team deemed 14 months of constant communication enough notification for customers and listeners to have made any necessary changes.

Professional aggregation services like Amazon.com, iTunes.com and iHeartRadio.com are NOT affected by the naming convention changes as they are under direct management of our infrastructure department. This includes professional terrestrial radio stations and affiliate media content providers Like SoniXFM, Roku, Sony and Rock-o-la.

Principally, NO customer should be using the cabhsxx prefix for listeners or 3rd party aggregation services like tunein.com or itunes.com as, per our broadcasting guidelines, those hostnames were reserved for live broadcasting only. However, even then, the relay/redirector network is more appropriate for live broadcasting as well.

The following server blocks were affected by the naming convention changes:

  • cabhs10 – cabhs29: Sony Interactive server block (managed internally)
  • cabhs30 – cabhs49: SoniXCast retail server block (managed by customers)
  • cabhs5x – cabhs69: iHeartRadio.com server block (managed internally)
  • cabhs7x – cabhs89: iTunes.com server block (managed internally)
  • cabhs9x – cabhs99: Amazon.com server block (managed internally)

Server blocks provisioned after July 15th, 2017 were already prefixed with the ‘bbxx’ naming convention.

The relay/redirector network is also not affected by the naming convention changes.

New SSL Relay Network

SoniXCast’s Relay Network now supports SSL (https)

For a while customers have been requesting SSL (https) support for the listen urls they give their listeners and for embedding on their secure websites and now we’re happy to announce that SSL support is finally here. Try it for yourself -> https://relay.sonixcast.com

Who needs SSL?

The https protocol is trusted by the internet community at large and bolsters the reputation of content providers. Hardly any serious provider (be it google.com or microsoft.com) would consider doing business without a secure connection to their website and more and more devices have begun requiring a secure (https) connection due to privacy concerns. Web browsers especially make it well known to the visitor whether the connection is secure or not and some security conscious listeners may actually move on if it is not. Therefore, it behoves all content providers (and radio stations) to offer SSL support on their website.

Those who already have SSL enabled will be able to eliminate the annoying ‘Mixed content types & security threats associated‘ message that usually is displayed when a unsecure link to their stream is embedded on their webpage. All-in-all offering SSL support will make your listeners trust you better and they will listen to your station longer.

The Challenge

SSL has been around for a while and is rich with configuration options. The challenge for us was to build a suite of profiles that would support as many devices and browsers as the less secure http protocol. The only practical way to achieve this was to test each device and browser type and generate logic that would enable or disable certain SSL features on a per device/browser basis. For example: Many older Java-based devices do not support TLS which is the defacto standard for smartphones. Or the browser application Internet Explorer 6 (IE6) (much more widespread as one would think) does not support encryption algorithms found in more modern browsers like FireFox or Chrome. Over 200 different devices and browsers have been tested and certified to date.

Now what do I do?

SSL (https) runs side-by-side with the http protocol, so there is nothing that you must do unless you want to. The Relay Network will continue to work as before. You just have the added option of using https instead of http in your listen urls if you like. End user devices and browsers will transparently handle the secure communication, so your listeners may not even notice the difference unless they are watching for it.

Performance and Scope

SSL is baked into just about everything, so theoretically there should be no performance difference between using http or https. There may be compatibility issues with older devices or browsers we have not yet certified where you might receive a security message, but with all the devices and browsers we’ve worked on, we think you will be hard pressed to find something that is not compatible.

Only AnyCastIP™ and the SoniXCast Media Server (SXMS) have been secured with SSL. The Redirect Network and direct stream access are as before unsecured. Read here for more information on the different types of networks that are offered to customers.

What is SSL?

SSL (Secure Sockets Layer) is the standard security technology for establishing an encrypted link between a web server and a browser. This link ensures that all data passed between the web server and browsers remain private and integral. SSL is an industry standard and is used by millions of websites in the protection of their online transactions with their customers.

To be able to create an SSL connection a web server requires an SSL Certificate. When you choose to activate SSL on your web server you will be prompted to complete a number of questions about the identity of your website and your company. Your web server then creates two cryptographic keys – a Private Key and a Public Key.

The Public Key does not need to be secret and is placed into a Certificate Signing Request (CSR) – a data file also containing your details. You should then submit the CSR. During the SSL Certificate application process, the Certification Authority will validate your details and issue an SSL Certificate containing your details and allowing you to use SSL. Your web server will match your issued SSL Certificate to your Private Key. Your web server will then be able to establish an encrypted link between the website and your customer’s web browser.

The complexities of the SSL protocol remain invisible to your customers. Instead their browsers provide them with a key indicator to let them know they are currently protected by an SSL encrypted session. All SSL Certificates are issued to either companies or legally accountable individuals.

Typically an SSL Certificate will contain your domain name, your company name, your address, your city, your state and your country. It will also contain the expiration date of the Certificate and details of the Certification Authority responsible for the issuance of the Certificate. When a browser connects to a secure site it will retrieve the site’s SSL Certificate and check that it has not expired, it has been issued by a Certification Authority the browser trusts, and that it is being used by the website for which it has been issued. If it fails on any one of these checks the browser will display a warning to the end user letting them know that the site is not secured by SSL.