Understanding IP Networks - Security and Firewalls
In the last article we looked at why we need security in a broadcast network. In this article we continue the theme of looking at a network from a broadcast engineers’ point of view so they can better communicate with the IT department, and look at how IT engineers implement network security.
Humans are Weakest Link
IP networks can be attacked at any time without warning. This could be from a malicious hacker wishing to exploit money from their victim, a bored enthusiast who wants to prove a point, or a political activist who wants to disrupt the activities of the company they have a grievance with.
In any security system humans are the weakest link. They inadvertently open links in emails which launch virus’s, download music and films from bit-torrents and even open illegal web sites.
Broadcast Engineers and Malicious Hacks
These security breaches are problematic for the IT network and infrastructure but they have not traditionally affected the broadcast equipment. As camera’s, vision mixers, sound desks and other IP enabled kit regularly run FTP, TCP and SSH protocols, it’s easy for attackers to gain access to the broadcast kit too.
Broadcast engineers need to seriously consider the effects of malicious hacks and attacks on their broadcast infrastructure and two strategies are available to us; prevention and detection.
Thousands of Protocols
Firewalls provide the best form of prevention from malicious hacks and are devices that sit in-line on the gateway to a network and monitor all of the incoming and outgoing IP packets deciding to pass, reject or drop them, all in real time under the control of the network administrator.
Firewall can be used to block hostile attacks from SSH and Telnet, but allow video and audio streams
There are thousands of protocols in the TCP suite ranging from HTTP web access to more obscure protocols such as “quote of the day”. Each protocol can increase network traffic and is a potential for a network attack.
Software Developer Armies
Open source code provides great opportunities to develop our knowledge and build better products, one of the downsides is malicious hackers also have access to the source code and they can use this to find vulnerabilities in the design and exploit them for their own needs. As vulnerabilities become evident they are quickly fixed by the community of developers and republished.
An army of software developers will peer review the code and soon let the authors know if there is still a problem and suggest ways to fix it. This is the single most important aspect of open source software and has led to improvements in the IT and broadcast industries.
Rule Tables
This loop continues and as a software service matures the number of vulnerabilities it is subject to decreases over time making the code more secure and resilient.
Propriety code suffers the same problems but we have to rely on believing the vendors when they tell us the vulnerability has been fixed. The software patch cannot be peer reviewed as we do not have access to the source code.
Through their rule tables firewalls restrict protocol access from the outside world and work on three levels; stateless, stateful and application.
Stateful Firewalls
In its simplest form stateless firewalls look at the source and destination addresses of IP packets travelling to and from the network without reference to any higher protocols. If we have a vision mixer with IP addresses 10.10.0.20 and 10.10.0.21, then we could add these to the firewall rules table to drop any packets with these as the source addresses leaving the network, and block any inbound network traffic with these addresses as destinations, resulting in the vision mixer not being able to communicate with the outside world, and the outside world will not see the vision mixer.
Stateful firewalls look at the higher level data flows and connection states. TCP is a connection based protocol and the source device must request a logical connection to the destination device. If an engineer wants to configure a camera using HTTP their browser will first request a TCP connection to the camera and a stateful firewall can detect this and log the event for later analysis.
Application configurations monitor at a service level for inbound and outbound traffic. Telnet is a utility based on TCP to allow command line access to a device such as a camera or vision mixer. Once the credential stage is passed then an engineer can gain access to any part of the device especially if they have administrator access. SSH is an encrypted version of Telnet providing a secure method of access to the camera and in the wrong hands both of these can be devastating for a broadcast infrastructure.
Launch Attack
The big problem with IT security is that the attacker may be anywhere in the world meaning they don’t have to have breached front door security of the television station. Without firewalls we don’t know if a network is being attacked or has been attacked. It’s possible that a malicious hacker might be monitoring and learning a network waiting for an opportune moment to launch their attack.
Taking this argument to the extreme we could put a firewall on every device on a network. This is impractical due to cost, administrative overhead and network delays. A compromise has to be struck to determine where is best to install firewalls and a network may have many situated throughout the estate.
Protect Playout
In a broadcast design we have the added challenge of keeping network jitter and delays low to allow error free distribution of real time video and audio. Firewalls, routers and switchers will inevitably cause varying amounts of packet delay and jitter. Even choosing the type of firewall can change delays, a stateful configuration is much slower than a stateless one.
Generally speaking each studio, client playout system or pool of edit suites should have its own firewall and subnet. If one studio is compromised, then the firewall can be used to block the effect on the rest of the network.
In the past, broadcast engineers have been used to pulling U-links and patch cords to isolate broadcast systems. In the IT world we don’t have this luxury as resilient networks will automatically route to other links when cables are removed, and removing an Ethernet cable in a studio network could also stop access for the PC’s, vision mixers, sound desks or cameras.
You might also like...
Designing IP Broadcast Systems - The Book
Designing IP Broadcast Systems is another massive body of research driven work - with over 27,000 words in 18 articles, in a free 84 page eBook. It provides extensive insight into the technology and engineering methodology required to create practical IP based broadcast…
Demands On Production With HDR & WCG
The adoption of HDR requires adjustments in workflow that place different requirements on both people and technology, especially when multiple formats are required simultaneously.
If It Ain’t Broke Still Fix It: Part 2 - Security
The old broadcasting adage: ‘if it ain’t broke don’t fix it’ is no longer relevant and potentially highly dangerous, especially when we consider the security implications of not updating software and operating systems.
Standards: Part 21 - The MPEG, AES & Other Containers
Here we discuss how raw essence data needs to be serialized so it can be stored in media container files. We also describe the various media container file formats and their evolution.
NDI For Broadcast: Part 3 – Bridging The Gap
This third and for now, final part of our mini-series exploring NDI and its place in broadcast infrastructure moves on to a trio of tools released with NDI 5.0 which are all aimed at facilitating remote and collaborative workflows; NDI Audio,…