|Systems for delivering and exchanging consistent volumes of data across networked environments.|
Technologies such as audio conferencing, video conferencing, chat rooms, remote access, and collaboration systems are called realtime, or streaming, services. They all involve consistent and prolonged exchanging of information.
Many client/server applications have short, simple communications. Take the web, for example. A web browser makes a connection to a web server. While that connection is open, the browser will send a request. The server will send back a response, usually either a web page or an image, and then the connection is closed. One request/response, one connection. If the browser loads more than one page from a single server, each subsequent request is a brand-new connection. This is the most efficient way for the web to operate because requests from any one browser come few and far between. It’s also efficient for other common Internet applications such as email, ftp, and newsgroups.
There are plenty of applications that have much more complex communication requirements. Take remote access, for example. The client and server are in constant communication, sending requests and responses back and forth. While many server responses are generated due to client requests (key presses, mouse movements), sometimes the server needs to update the client without a directly corresponding request (an error message or notice from a program). The only way to efficiently handle this is to leave the connection open, or to operate using a connectionless data protocol. This constant flow of data is often referred to as a “stream”.
The concept of streaming information sounds simple, but is difficult in practice. The Internet is an incredibly complex system where two machines may be separated by thousands of miles and a dozens of intermediary systems. In order to guarantee that data gets from one place to the next, a system of verifications can be used (the Transmission Control Protocol, or TCP as describe in chapter 25). The problem is that these verifications take up bandwidth and processing time, which in turn limits the immediacy and/or quality of the communication. For applications such as video conferencing, this limitation can cause the picture to stutter, skip or have an unbearable delay (like what used to happen when making international phone calls, years ago).
Audio and video are the most data-intensive realtime applications. They're also very sensitive to lag -- a two second delay can make an audio/video conference unbearable. Remote access and control systems also need rapid response; otherwise many graphical interfaces become unusable. Chat applications and instant messaging are low bandwidth and the least sensitive to lag. This is mostly because text is sent in chunks, a sentence or two at a time. The typing speed of the user is a bigger constraint than the network performance. For this reason, text-based chat is a preferable form of communication in low bandwidth or high-latency situations.
What People Think: Instant messaging and audio/video streaming are fun and potentially productive additions to the work environment. Instant messaging is so big we must adapt to support its use in our company.
What We Think: These are cans of worms that can easily bring more in security risk to an organization than productivity benefit.
How It Works
There are two basic techniques for streaming information. If the bulk of the stream is generally one directional, then a client-server model is used. If both ends are sending and receiving similar quantities of data, a peer-to-peer model is preferred. The peer-to-peer model is discussed in a separate chapter. Here, we'll look at the client-server model.
When you listen to an Internet radio station, you’re really connecting to a powerful server. This server is capable of maintaining a certain number of simultaneous audio streams. That number is determined by two factors: the bandwidth available to the server and the license of the software used to stream the data. The performance (processing power and hard drive speed) of the server is not really relevant; you’ll max out either bandwidth or licensing before you max out the server.
For example, Real Network’s Helix server can handle up to 10,000 simultaneous connections on standard entry-level server hardware. But that number is severely limited by the available bandwidth and the license terms. The basic license only allows for up to 1 Megabit of simultaneous data (a T1 has 1.44Megabits of capacity). Assuming users connect at an average of 50Kbps, this practically limits the server to 20 simultaneous connections.
Bandwidth: Most realtime applications have more data going in one direction than another. Take Internet radio, for example. The client sends infrequent commands, usually just requesting a change of station. The server, on the other hand, is sending a constant stream of data back to the client. This imbalance creates a natural denial of service situation. The inbound bandwidth can get maxed out from just a handful of radio players, while the outbound bandwidth remains relatively untapped. This means that players can keep requesting new radio streams, which keep clogging up the inbound bandwidth.
There are a number of solutions to this problem. Firewalls and proxy servers, traffic shaping system and client configurations can all control the bandwidth used. Traffic shaping can be used to limit the total inbound bandwidth allocated to streaming media. But differentiating between "good" streaming media (video conferencing, training) and "bad" media such as music is hard. Firewalls and proxies can be used to help make the differentiation, but this process requires constant attention. An exception rule would need to be made for every "good" media source.
Firewalls: An audio or video server can send information to a client using either an open connection (TCP) or by sending connectionless data directly to the client (UDP). Most firewalls will not allow unsolicited packets through. This isn't a problem for TCP, because each TCP packet is associated with a connection. The firewall just has to note which connections were created internally and allow corresponding TCP packets back through. This is called keeping state.
It's hard to tell if a UDP packet was requested because there's no connection. Keeping state with UDP is only possible by making guesses about incoming packets based on previous outgoing traffic. This isn't very secure, and a hacker could easily hijack a UDP session by fooling the firewall. As a result, many firewalls don't effectively handle UDP connections. Those that do are exposing the network to an additional degree of risk, albeit fairly minor and hard to exploit.
This has prompted most streaming media software providers to allow TCP-only streaming. The performance is worse, but with today’s bandwidth and processors it’s not too terrible. In the same vein, they have also worked around restrictive firewalls by allowing the applications to stream data over the channel normally used for web communications (TCP port 80). This makes it impossible for firewalls to differentiate between streaming media traffic and normal web traffic.
Thought: could a coordinated hacker use streaming services to deny service to a site? Redirect a lot of streaming traffic to one site?
Digital Rights Management: It is very difficult to control content once it has been broadcast in any medium. People record songs off the radio and tape TV programs and pay-per-view movies. Broadcasting to computers makes it even easier for the end users to create digital copies that can be preserved and passed around. Content providers have used existing DRM solutions to “lock” the content, theoretically preventing users from recording broadcasted content. But these solutions are effectively broken. Numerous third-party software packages exist that can copy or record a digital broadcast. If you can see it, it can be recorded.
Social Engineering: Two classes of users frequently use chat rooms and instant messaging: computer novices (newbies) and malicious hackers (script kiddies). That makes for a pretty dangerous situation. The problem is that the hackers exploit the naivety of the novices, convincing them to install trojan programs. They can also take advantage of some automatic features of chat applications, such as forcing a web browser to open or go to a specific web page. That web page can contain an exploit that in turn can install a trojan.
Chat rooms are a serious channel for social engineering. Employees who use chat and instant messaging from the office may be inadvertently giving out critical knowledge to unknown third parties. This information can be later used to social-engineer into a network. For example, a hacker could guide conversation into gripes about work. The hacker already knows the name of the company: a quick lookup based on the IP address of the worker gave the company’s domain name. During the conversation, the hacker might find out the secretary’s name, and enough information to specifically identify the user. Two days later, a call might come in, “Is this Jeanne, Bob Johnson’s assistant? This is Jim from Dell Support. Bob had notified us of a problem with his system. Oh, he’s out of the office today? We have a diagnostic application that he needs to run; can we email it to you? It will speed up our repair time dramatically.” Forging the email from Dell is trivial. Before Bob returns, Jeanne will have installed a trojan program, fully believing that she was legitimately helping Bob fix his PC.
Application Bugs: The applications themselves are often problematic – features, not security, are the selling point for many realtime applications. Some of the features are conceptually insecure; others are implemented incorrectly and can contain serious security vulnerabilities.
Bugs in chat, conferencing and messaging applications allow hackers to install trojans without any effort – they just send automated programs (called bots) to every channel and attempt to hack everyone online. Anybody using the bugged software will end up with a trojan on their system, most likely without their knowledge.
Often a bug isn’t even necessary. Many chat programs allow a user to send a file to another user. Sometimes the receiving user doesn’t even know they’re getting the file! Likewise, various streaming media formats can force a web browser to open and visit a page that exploits the browser and installs a backdoor into the system.
Information Visibility: When sending an instant message, who else is watching? Some instant messaging applications are peer-to-peer. A central server helps people figure out if others are online, but the actual connection is between one user and another. Other systems act as middlemen, passing messages between parties. Most chat rooms function this way, as peer-to-peer chatting means sending the same message out to each peer.
Most streaming systems are not encrypted. Performance is enough of an issue without adding the overhead of encryption. This lets anyone along the data path to see the entire stream of information.
Making The Connection
Firewalls: can be configured to prevent streaming media access, but this will also greatly restrict other types of access
DRM: many commercial media streaming systems support DRM systems. While these can be broken, they make matters somewhat more difficult.
Core Networking Protocols: In order to understand streaming services, it helps to understand the fundamental systems that make the Internet work
The best solution is to use policy and monitoring and control systems to enforce the policy. For example, a company could block access to Internet radio, instead offering its employees access to music via an internal mp3 server.
The above information is the start of a chapter in "Network Security Illustrated," published by McGraw-Hill and available from amazon.com, as well as your local bookstore. The book goes into much greater depth on this topic. To learn more about the book and what it covers, click here.
Below, you'll find links to online resources that supplement this portion of the book.