Like it or not, broadcast engineers must pay close attention to network security. After all, we’ve seen what can happen to a station when the proper amount of diligence isn’t applied. In this article, we’re going to cover the use of the public internet for business, and specifically, making use of virtual private networks.
A LITTLE HISTORY
Twenty-five years ago, most computers around a radio station were used for traffic, billing and accounting purposes. In the mid-1990s, stations started adding direct internet connections. Though there were many obvious things a station could do, there were also, not surprisingly, unintended consequences from the connection.
Once you open a window to the rest of the world, it should come as no surprise that someone on the outside would try to sneak in through it. Such is the public internet.
BASIC FEATURES OF VPN
VPNs are very secure and a great way to keep the bad guys out of your network, while allowing legitimate users the remote access they need. Before discussing applications of VPN, let’s talk a little about just what it does. Use of VPN facilitates the following security features:
Authentication. Verification is provided to make sure the packets are coming from a legitimate source, and not someone else in the middle (that is, somewhere else out in the world). The packets are encrypted and can only be decrypted by the receiving computer or VPN endpoint. Authentication ensures that only the people that are supposed to see the packets actually do.
Integrity. Packets are verified so that the receiver knows they weren’t modified along the way.
Antireplay. This is a feature that prevents someone in the middle from copying the packets and resending them later. The bad guys can copy a stream of data on the internet, modify it ever so slightly, and then play it out to the receiving device, which in turn thinks the data came from a legitimate source and allows it into the network. This is just one way your network can be compromised.
Privacy. No one in the middle can read the data transported by the packets because they are encrypted and only the receiving end can decrypt them. The data looks like scrambled garbage to everyone except the user that can authenticate it.
These features are accomplished by the establishment of a VPN tunnel between two edge devices (that is, two devices that have an interface connected to the public internet). In this context, “tunneling” means that the packets are encapsulated by inserting them within another packet. A VPN tunnel means that the encapsulated packet has been encrypted — making it indecipherable to anyone that happens to pick it out as it transits a network.
The VPN devices also add extra headers to the encapsulated packet, with fields that allow for the security features described. When packets are received by way of the tunnel, they’re stripped of the extra header, de-encrypted, and then sent out on to the local network that is behind the VPN device. The sending device and receiving device usually are not aware that the packets sent and received have ever been through a tunnel. When implanted between routers, VPN tunnels are transparent to all devices on the network. Only the edge routers see the VPN packets and can decrypt them.
COMMON USES OF VPN
Network security issues notwithstanding, it’s clear that there’s no going back; the public internet is ubiquitous and cheap, and its problems are far outweighed by its usefulness. One must learn to live with its inherent dangers, and one way to do that is by using VPN.
(A note on the scope of this article: We’re not going to cover the details of system configuration for VPN — meaning neither command line nor web-based methods. We’ll discuss action items towards the end so that you can still get such systems implemented.)
Some of the most common uses of VPN are as follows:
Remote VPN client. (See Fig. 1) If you work for a larger broadcaster that has a corporate IT department it’s likely you already work within corporate policy that includes use of VPN. On the other hand, if you work for a smaller organization, you may not have gotten quite this far yet. When working from a remote location (such as home) the remote computer will make use of a client that, when opened, establishes a secured connection to your LAN. Your remote computer, for all intents and purposes, is on the remote LAN. This naturally comes in very handy if you want to work from home or some other remote place. All the other hosts on the LAN can be accessed as though you were plugged in to the same layer-2 switch.
Remote talent with automation. (See Fig. 2) I have worked with at least one circumstance of a remote talent who required our automation system at home and needed to do WAN-casting from there. That person was working from home, just like anyone else could — but clearly the situation was slightly more complicated. In reality, this talent could, by way of the VPN connection, place carts in to any station’s automation, anywhere in the company, all across the country. A simple cable-modem provided the physical layer connection to the internet.
Remote office. (See Fig. 3) Working from home usually means opening the VPN client and closing it when finished. However, you may have a situation with a remote office — for example, a sales office in another town — that needs a permanent, secure connection to your headquarters. In this situation, both ends would have a VPN router, and the two would make a secure connection that would remain in place all of the time. In this way, two geographically separate networks can appear to all users to be one single LAN. A variation on this idea is for the VPN connection to be used over the public internet in the event that a regular, point-to-point connection provided by the local Telco goes down.
Remote transmitter site. (See Fig. 4.) Clearly a remote transmitter site can be considered as a remote office. Having it as part of the same LAN can be very handy while you are in the office during the week — since connections to remote hosts are going to be easy to make — in fact, just as easy as any other connection around the station. In some instances the same kind of functionality can be achieved through the use of port-forwarding through a firewall located at the remote site. The advantage to the remote user is that no VPN client is necessary; the disadvantage is that your firewall could be hacked.
IMPLEMENTATION
As I wrote earlier, VPN configuration is beyond the scope of this article, but I will suggest means by which you can still see that it is used to provide security for your use of the public internet.
If you happen to have the IT chops to configure VPN yourself, then take a look at the scenarios presented above and if appropriate, put them to use.
If your station has a separate IT department familiar with VPN configurations, then discuss the ideas presented earlier and see if any are appropriate for your station or facility.
It is possible that engineering and IT simply have not previously discussed network security as it relates to a transmitter site (as one example). We all know that there are many IT day-to-day issues that are fires, and infrastructure issues sometimes slip through the cracks.
If you are by yourself without the time to learn how to set up VPN connections then consider hiring a local IT consultant to help you through the implementation. Sure, it will have a cost, but it’s cheap compared to the expense involved in fixing the consequences of poor network security.
AOIP CONNECTIONS THROUGH THE VPN TUNNEL
One of the most common uses of the public internet is the transmission of audio over IP and you may be doing that already for “nailed up” connections like an STL. The addition of VPN between the two ends will not adversely affect AoIP connections according to the manufacturers with whom I communicated for this article, which include Comrex, Telos, Tieline and Worldcast Systems.
Though it represents one extra step in configuration, and one extra on-going function to maintain, the use of VPN is a great way to secure your internal networks, hosts and all the features for which they are used.
My thanks to Chris Cottingham for his help in the preparation of this article.
