Flash Communication Server Article

Attacks and Firewalls

Firewalls are an essential tool in protecting networks from attacks. A firewall can pay for itself several times over by preventing a large number of attacks that could disable or corrupt production systems; this wastes many IT staff hours as they repair and recover compromised systems.

The "Slammer" worm, introduced in late January of 2003, is a good example of why organizations use firewalls. The worm exploits a vulnerability in certain versions of Microsoft SQL Server 2000 and Microsoft Desktop Engine 2000. The worm spreads by trying to gain access to the resolution service of the software by sending UDP packets to port 1434 for randomly chosen IP addresses.The worm could not penetrate networks that blocked UDP traffic on port 1434; they were immune from the worm. But networks that did not block the worm were infected if the worm found any system with unpatched versions of the two Microsoft products. Unfortunately, insecure networks that didn't protect systems from the incoming worm were likely to let their infected systems propagate the worm externally to other networks.

The Slammer worm only exploits one vulnerability in two products from one vendor. But there are many other vulnerabilities in many different operating systems and applications. The technical community discovers new vulnerabilities all the time. Read the advisories at http://www.cert.org/ to get an idea of the scale of this problem. Applying security patches to software with vulnerabilities is one important part of securing a network—but it is only one part. A firewall is absolutely essential. The Slammer worm also illustrates why IT security groups apply very restrictive rules when they set up firewalls. For instance, some organizations had well-protected and well-patched core production systems but weak firewall rules. When the worm was released, they discovered that a few unpatched workstations or test systems completely disabled their entire network. The worm did not affect their core production systems, but still rendered these systems because the worm generated so much network traffic that no one could connect to them.

The rules for a well-configured firewall normally begin by denying all network traffic into and out of an organization's network. Then additional rules open access under a few carefully selected circumstances. The rules applied by any organization will be different depending on the needs of each organization. The rules will involve a number of settings:

• What IP addresses inside the firewall are reachable from the outside? If a computer on the Internet requests a connection to a machine on the local network, will the firewall pass the request to the machine or block it?
• If you allow outside users to reach an IP address inside the firewall, what type of traffic do you permit—TCP and/or UDP? TCP, or Transport Control Protocol, is the basic protocol on which many other common protocols such as HTTP are based. It is a reliable and bidirectional protocol. UDP, or User Datagram Protocol, is an unreliable protocol. With UDP, there is no built-in guarantee that all packets will arrive. You can use UDP to send information to one or many addresses. Many streaming media servers use UDP, however, the Macromedia Flash Communication Server MX uses TCP.
• If a user can reach an IP address inside the firewall using either UDP or TCP from the outside, what port or ports are accessible? Port numbers are the addresses of applications running on the machine. For example, connecting to port 80 normally means the request goes to a web server, if one is available. A request to port 443 typically goes to a system that provides an SSL service that encrypts data as it passes it back and forth between the server and a remote client. Another common application is mail services, which typically use port 25 to listen for incoming mail using the Simple Mail Transport Protocol (SMTP). Even though you may not specify a port number when using an application, all IP connections involve a connection request to a specific port number, using a specific basic protocol, such as UDP or TCP.
• Is a connection request initiated from outside the firewall or from inside an organization's network? Most firewalls can distinguish between internal and external requests. These "stateful" firewalls keep track of sessions and can permit sessions (the flow of traffic back and forth across the firewall) that are only initiated from systems inside the firewall. For example, a workstation can request a connection to an outside web server, but no outside system can initiate a connection to the workstation.
• Does the firewall work at the application layer or at the network layer? Most firewalls operate at the network layer and are unaware of the actual data or payload carried within network packets. Some firewalls work at the application layer and can examine the data carried within network packets and understand protocols such as HTTP and SMTP. You can configure application-layer firewalls to only permit valid HTTP and SMTP traffic and exclude everything else.

Now imagine an organization pays you to set up a firewall to protect its network. What rules would you put in place? For example:

• What IP addresses would you allow remote systems to talk to when the remote system (outside your firewall) initiates the connection?
• When a remote system is allowed to initiate a connection to an IP address, which ports on the systems do you allow it to connect to?
• Are systems within your firewall allowed to make requests to systems outside the firewall?
• If systems can request connections to outside the firewall, are they restricted to certain remote IP addresses?
• If systems can request connections outside the firewall, are they restricted to certain well-known ports, such as port 80 for HTTP?
• Should you use an application-layer firewall to examine data from outside the firewall to ensure it conforms to a protocol or format, like HTTP, SMTP or HTML?

Given these questions, let's see how each decision might affect the ability of a Macromedia Flash movie to connect to a Flash Communication Server. We’ll start by looking at how firewalls can affect the ability a Macromedia Flash movie has to connect to a communication server using Macromedia Real-time Messaging Protocol (RTMP) and explore some common workarounds. RTMP is the protocol Macromedia Flash movies and the communication server use to send and receive audio, video, and data in real time. Then, let's look at cases where firewalls or proxy servers block all RTMP connections and see how tunneling makes it possible to move RTMP communications through an HTTP tunnel.

Controlling Connections Initiated from Outside a Firewall

Normally, an administrator sets up a firewall to block connections initiated from outside except for connections to certain servers that must be available to the outside world. For example, the administrator must allow access to port 80 on a web server (at a specific IP). Or, if a web server uses another port such as 8080, the administrator would allow the connection to that port. Also, the administrator may need to allow or open port 443 for SSL-encrypted web access. Similarly, the administrator would allow access to port 25 for the IP address of a mail server.

These restrictions only affect Macromedia Flash Communication Server connections if you want to run the server inside a firewall and make it available to the outside world. By default, the server accepts connections from Macromedia Flash movies on port 1935. That means port 1935 for the communication server IP address must be open on the firewall. Figure 1 shows a successful connection in a configuration where there is no firewall between a remote workstation and Flash Communication Server. Figure 2 shows a deliberately oversimplified configuration in which a firewall permits access to port 80, but not to port 1935. The simplest solution is to open access through the firewall to port 1935, as shown in Figure 3.

Figure 1. A direct RTMP connection request to a host running Macromedia Flash Communication Server. A web server runs on the same host as the communication server and is available at port 80. Macromedia Flash Communication Server is available at port 1935.

Figure 2. A connection request blocked by a firewall that does not permit outside requests to port 1935

Figure 3. Opening a "hole" in the firewall to allow access to the communication server default port

You can also configure Macromedia Flash Communication Server MX to accept connections on ports other than 1935, or on more than one port at the same time with the <HostPort> tag in the Adaptors.xml file. For example, use the following <HostPort> tag to have the communication server accept connections on ports 1935, 8080, 443, and 80:

<HostPort>:1935, 8080, 443, 80</HostPort>

If another service is running on the same server at the same IP address, do not configure the communication server to listen on the same port. For example, if a web server is using port 80 or 443, Macromedia Flash Communication Server cannot use these ports. If you are not hosting your own Macromedia Flash Communication Server, contact your hosting service to see what ports the communication server uses.

The communication server administrative server normally runs on port 1111. It is a good idea to leave port 1111 blocked so that an attacker cannot reach it. However, administrators and developers working remotely may want access to port 1111 to use the administration and app_inspector movies. This poses a conflict between convenience and security. Hosting services will have to leave port 1111 open and use virtual hosts and logins to control what remote users can do. Institutions that do not provide hosting services may not have to open port 1111. If they must allow remote access to port 1111, these providers can control the IP addresses that can reach 1111 using a firewall, or by using the <Allow> and <Deny> tags in the Server.xml file. A better solution for these institutions is to install a virtual private network to allow authenticated access through the firewall, leaving port 1111 blocked for outside users.

Controlling Connections Initiated from Inside a Firewall

Macromedia Flash Communication Server MX never has to connect to a Macromedia Flash movie—Macromedia Flash initiates a connection from the client. If a firewall lets workstations connect to any port on any system outside the firewall, there will be no connection problems. For example, this kind of firewall set up would permit the following sequence of events:

1. A user's browser requests a web page containing a SWF file from a remote web server on port 80.
2. After downloading the SWF and playing it within the browser, the SWF connects to Macromedia Flash Communication Server at port 1935.

In both cases the user's workstation initiated the request so everything works fine. The firewall will remember that the user's workstation requested the connection to port 1935 and it will let the data move back and forth between the workstation and the server.

Many organizations restrict the ports that local workstations can use to request connections outside the firewall. Some may restrict access only to the ports commonly used by web servers. The most common web server ports are 80 for HTTP and 443 for HTTPS. Web servers often use port 8080 as a secondary address for HTTP.

Figure 4. A firewall that does not permit requests on port 1935 blocks client access to Macromedia Flash Communication Servers outside the firewall.

The simplest solution to the problem of port 1935 being blocked is to set up the communication server to also accept network connections on ports 443 and/or port 80. This assumes no other service is using those ports on the same IP address that your communication server is using. (We'll return to this in a moment.) To listen on ports 1935, 443, and 80 use a host port tag in the Adaptors.xml file:

<HostPort>:1935, 443, 80</HostPort>

Or, if you need to identify a specific IP address for an adaptor, use:

<HostPort>XXX.XXX.XXX.XXX:1935, 443, 80</HostPort>

where XXX.XXX.XXX.XXX is the IP address.

In many cases, this is all you need to get past many firewalls without even using HTTP tunneling. This works because of a feature built into the NetConnection object. When you do not specify a port number in an RTMP address, Macromedia Flash will attempt to connect to port 1935. If it fails it will then try to connect to port 443; if that fails, it will try port 80. So no coding is required to access ports 1935, 443, or port 80 if you do not specify a port in the RTMP address.

Figure 5. A successful connection request to the communication server on port 80.

Note: The web server shown earlier no long uses port 80.

Here is a fictitious example of a full URI without a port number:

nc.connect("rtmp://host.domain.com/myApp/myInstance");

Here is an example of a relative URI without a port number:

nc.connect("rtmp:/myApp/myInstance");

The relative URI only works if the communication server is available from the same host address as the web server where you downloaded the SWF from.

If Macromedia Flash Communication Server MX accepts connections on ports 1935, 443, and 80, and the firewall lets the workstation connect on one of these ports, the connection will succeed. When a web server is running on the same server as the communication server, port 80 and possibly port 443 may not be available. Here are some solutions to this problem:

• Don't put a web server on the same machine that runs Macromedia Flash Communication Server. While this may not always be possible, it's a good idea. You don't have to worry about sandbox security restrictions when the web server is on a different host. A Macromedia Flash movie can attempt to connect to any Macromedia Flash Communication Server, so serving your SWFs from a different host is not a problem.
• Configure the machine you are using as a server to answer at two separate IP addresses associated with different host names. You can use two separate network cards to do this, or in some cases you may even be able to use a single network adapter. Then, configure your web server to run on one IP and the communication server on the other IP.
• Configure your web server to only accept connections on ports 8080 and possibly on port 443, leaving port 80 available for the communication server. The problem with this approach is that some firewalls may block access to your web server if they only allow access to port 80.

Another option is to configure Macromedia Flash Communication Server to accept connections on port 8080. There are two drawbacks to this. One is that many firewalls block port 8080. The other is that you have to explicitly attempt to connect to port 8080 using ActionScript in your Macromedia Flash movies. For example, if the movie fails to connect to ports 1935, 443, and 80, then the NetConnection's onStatus() handler will receive an information object indicating the connection attempt failed (NetConnection.Connect.Failed). At that point, you can try to connect again using another port number. Here is an example of a full URI with the port number 8080 included:

nc.connect("rtmp://host.domain.com:8080/myApp/myInstance");

Here is an example of a relative URI with a port number:

nc.connect("rtmp::8080/myApp/myInstance");

When you specify a port number, Macromedia Flash will only attempt to connect using the port number you supply.

A Note on XML Socket Servers

Macromedia Flash Player treats XML socket connections differently than it does RTMP connections. XML socket connections are only allowed to host ports 1024 or higher. Port 8080 would be permitted, but 443 and 80 are not. Also, the player's sandbox restrictions apply to HTTP (through loadVars and so forth) and XML socket connections (through XMLSocket), but not to RTMP connections through NetConnection objects. Removing normal sandbox restrictions make it possible for organizations to use an outside provider's Flash Communication Server while hosting Macromedia Flash files on their own web server. If you are concerned about controlling access to your Flash Communication Server from movies originating in other domains, see the section on Domain Restrictions below for how to control access at the server.

Application-Layer Firewalls

If firewalls only allowed or denied connections based on IP addresses and ports, there would be no need for HTTP tunneling. In simple terms, all you would need to do is configure Macromedia Flash Communication Server to accept connections on port 80. Anyone with web access could then connect to your communication server. However, application-level firewalls can inspect the data within packets as they travel over the network to see if they conform to the protocol normally associated with a certain port. In the case of port 80, these firewalls usually look for properly formatted HTTP headers and HTTP transactions. When someone attempts an RTMP connection over port 80, it doesn't resemble an HTTP transaction. An application-layer firewall detects this and denies the connection request.

Figure 6. A firewall that only allows HTTP transactions blocks a request for an RTMP connection on port 80.

HTTP tunneling makes it possible to get around this problem. Instead of maintaining a simple RTMP connection, Macromedia Flash Player and Flash Communication Server can exchange RTMP data such as video, audio, and ActionScript data by wrapping the RTMP information inside HTTP-formatted requests. For example, Macromedia Flash Player sends a request that begins with a standard HTTP header followed by RTMP data (the data is not shown here).

POST /send/20250680/0 HTTP/1.1
POST /send/20250680/0 HTTP/1.1
User-Agent: Shockwave Flash
Host: myHost.myDomain.com:80
Content-Length: 1537
Connection: Keep-Alive
Cache-Control: no-cache

The server responds with an HTTP header (shown below) followed by additional data.

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Length: 3074
Cache-Control: no-cache
Server: FlashCom/1.5

To maintain the same type of constant open communications as RTMP provides, the player polls the server constantly with HTTP requests. Polling the communication server with regular requests and wrapping data inside HTTP requests is less efficient than pure RTMP. So, in general, you should attempt to use RTMP when you can—resort to HTTP tunneling only when you have to. When RTMP is tunneled though HTTP it is referred to as RTMPT.

Fortunately, using HTTP tunneling is not difficult. It is built into version 1.5 of the server and Macromedia Flash Player versions 6,0,65,0 and later. You can make either regular RTMP or RTMPT connections on any port on which Macromedia Flash Communication Server accepts connections.

Macromedia Flash Player also has a couple of additional features. First, it lets you specify a new protocol within connection URIs. For example, you can explicitly specify the RTMPT protocol in an attempt to connect to a server using HTTP tunneling, as follows:

nc.connect("rtmpt://host.domain.com/myApp/myInstance");

When you use RTMPT in a URI and do not specify a port, Macromedia Flash Player will attempt to connect to port 80 using HTTP tunneling.

Second, the default behavior of the Macromedia Flash Player was extended to include a fourth connection attempt using RTMPT. When the URI specifies RTMP as the protocol, but doesn't specify a port:

nc.connect("rtmp://host.domain.com/myApp/myInstance");

Macromedia Flash Player versions 6,0,65,0 and later attempt connections through the following ports and protocols in the order listed. If a connection using the first protocol and port combination fails, then it will try the second one and proceed down the list.

Figure 7. Four attempts to get through a firewall. Attempts one, two, and three using the RTMP protocol fail. The fourth attempt succeeds when you use RTMPT on port 80.

‹ Back | Contents | Next ›

Submit feedback on our tutorials, articles, and sample applications.