Enabling Common TCP Services

It's likely that no one will want to enable all the services listed in this section, but most everyone will want to enable some subset of them. These are the services most often used over the Internet today. As such, this section is more of a reference section than anything else. This section provides rules for the following:

• Email

• Usenet

• Telnet

• SSH

• FTP

• Web services

• Whois

• RealAudio, RealVideo, and QuickTime

Many other services are available that aren't covered here. Some of them are used on specialized servers, some are used by large businesses and organizations, and some are designed for use in local, private networks. Additional LAN and DMZ services are covered in Chapter 6.

Email (TCP SMTP Port 25, POP Port 110, IMAP Port 143)

Email is a service that almost everyone wants. How mail is set up depends on your ISP, your connection type, and your own choices. Email is sent across the network using the SMTP protocol assigned to TCP service port 25. Email is commonly received locally through one of three different protocolsSMTP, POP, or IMAPdepending on the services your ISP provides and on your local configuration.

SMTP is the general mail protocol. Mail is delivered to the destination host machine, as defined most commonly by the MX record in the DNS for the given domain. The endpoint mail server determines whether the mail is deliverable (addressed to a valid user account on the machine) and then delivers it to the user's local mailbox.

POP and IMAP are mail-retrieval services. POP runs on TCP port 110. IMAP runs on TCP port 143. ISPs commonly make incoming mail available to their customers using one or both of these two services. Both services are usually authenticated by username and password. As far as mail retrieval is concerned, the difference between SMTP and POP or IMAP is that SMTP receives incoming mail and queues it in the user's local mailbox. POP and IMAP retrieve mail into the user's local mail program from the user's ISP, where the mail had been queued remotely in the user's SMTP mailbox at the ISP. Table 4.3 lists the complete client/server connection protocols for SMTP, POP, and IMAP. SMTP also uses specialized delivery mechanisms that your local network might use, such as ETRN, that effectively transfer all mail for a given domain for local processing.

Table 4.3. SMTP, POP, and IMAP Mail Protocols

DESCRIPTION	PROTOCOL	REMOTE ADDRESS	REMOTE PORT	IN/OUT	LOCAL ADDRESS	LOCAL PORT	TCP FLAG
Send outgoing mail	TCP	ANYWHERE	25	Out	IPADDR	1024:65535	Any
Remote server response	TCP	ANYWHERE	25	In	IPADDR	1024:65535	ACK
Receive incoming mail	TCP	ANYWHERE	1024:65535	In	IPADDR	25	Any
Local server response	TCP	ANYWHERE	1024:65536	Out	IPADDR	25	ACK
Local client query	TCP	POP SERVER	110	Out	IPADDR	1024:65535	Any
Remote server response	TCP	POP SERVER	110	In	IPADDR	1024:65535	ACK
Remote client query	TCP	POP CLIENT	1024:65535	In	IPADDR	110	Any
Local server response	TCP	POP CLIENT	1024:65535	Out	IPADDR	110	ACK
Local client query	TCP	IMAP SERVER	143	Out	IPADDR	1024:65535	Any
Remote server response	TCP	IMAP SERVER	143	In	IPADDR	1024:65535	ACK
Remote client query	TCP	IMAP CLIENT	1024:65535	In	IPADDR	143	Any
Local server response	TCP	IMAP CLIENT	1024:65535	Out	IPADDR	143	ACK

SENDING MAIL OVER SMTP (TCP PORT 25)

Mail is sent over SMTP. But whose SMTP server do you use to collect your mail and send it onward? ISPs offer SMTP mail service to their customers. The ISP's mail server acts as the mail gateway. It knows how to collect your mail, find the recipient host, and relay the mail. With UNIX, you can host your own local mail server, if you want. Your server will be responsible for routing the mail to its destination.

RELAYING OUTGOING MAIL THROUGH AN EXTERNAL (ISP) GATEWAY SMTP SERVER

When you relay outgoing mail through an external mail gateway server, your client mail program sends all outgoing mail to your ISP's mail server. Your ISP acts as your mail gateway to the rest of the world. Your system doesn't need to know how to locate your mail destinations or the routes to them. The ISP mail gateway serves as your relay.

The following two rules enable you to relay mail through your ISP's SMTP gateway:

 SMTP_GATEWAY="my.isp.server"          # external mail server or relay if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \              -s $IPADDR --sport $UNPRIVPORTS \              -d $SMTP_GATEWAY --dport 25 -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          -d $SMTP_GATEWAY --dport 25 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          -s $SMTP_GATEWAY --sport 25 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT 

SENDING MAIL TO ANY EXTERNAL MAIL SERVER

Alternatively, you can bypass your ISP's mail server and host your own. Your local server is responsible for collecting your outgoing mail, doing the DNS lookup on the destination hostname, and sending the mail to its destination. Your client mail program points to your local SMTP server rather than to the ISP's server.

The following two rules enable you to send mail directly to the remote destinations:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \              -s $IPADDR --sport $UNPRIVPORTS \              --dport 25 -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          --dport 25 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          --sport 25 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT 

RECEIVING MAIL

How you receive mail depends on your situation. If you run your own local mail server, you can collect incoming mail directly on your Linux machine. If you retrieve your mail from your ISP account, you may or may not retrieve mail as a POP or IMAP client, depending on how you've configured your ISP email account, and depending on the mail delivery services the ISP offers.

RECEIVING MAIL AS A LOCAL SMTP SERVER (TCP PORT 25)

If you want to receive mail sent directly to your local machines from anywhere in the world, you need to run sendmail, qmail, or some other mail server program. These are the local server rules:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A INPUT  -i $INTERNET -p tcp \              --sport $UNPRIVPORTS \              -d $IPADDR --dport 25 \              -m state --state NEW -j ACCEPT fi $IPT -A INPUT  -i $INTERNET -p tcp \          --sport $UNPRIVPORTS \          -d $IPADDR --dport 25 -j ACCEPT $IPT -A OUTPUT -o $INTERNET -p tcp ! --syn \          -s $IPADDR --sport 25 \          --dport $UNPRIVPORTS -j ACCEPT 

Alternatively, if you'd rather keep your local email account relatively private and use your work or ISP email account as your public address, you can configure your work and ISP mail accounts to forward mail to your local server. In this case, you could replace the previous single rule pair, accepting connections from anywhere, with separate, specific rules for each mail forwarder.

RETRIEVING MAIL AS A POP CLIENT (TCP PORT 110)

Connecting to a POP server is a very common means of retrieving mail from a remote ISP or work account. If your ISP uses a POP server for customer mail retrieval, you need to allow outgoing client-to-server connections.

The server's address will be a specific hostname or address rather than the global, implied ANYWHERE specifier. POP accounts are user accounts associated with a specific user and password:

 POP_SERVER="my.isp.pop.server"            # external pop server, if any if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \              -s $IPADDR --sport $UNPRIVPORTS \              -d $POP_SERVER --dport 110 -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          -d $POP_SERVER --dport 110 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          -s $POP_SERVER --sport 110 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT 

RECEIVING MAIL AS AN IMAP CLIENT (TCP PORT 143)

Connecting to an IMAP server is another common means of retrieving mail from a remote ISP or work account. If your ISP uses an IMAP server for customer mail retrieval, you need to allow outgoing client-to-server connections.

The server's address will be a specific hostname or address rather than the global, implied $ANYWHERE specifier. IMAP accounts are user accounts associated with a specific user and password:

 IMAP_SERVER="my.isp.imap.server"       # external imap server, if any if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \             -s $IPADDR --sport $UNPRIVPORTS \             -d $IMAP_SERVER --dport 143 -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          -d $IMAP_SERVER --dport 143 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          -s $IMAP_SERVER --sport 143 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT 

EXAMPLES OF REAL-WORLD CLIENT AND SERVER EMAIL COMBINATIONS

Four common approaches to client and server email combinations are described in this section:

• Sending mail as an SMTP client and receiving mail as a POP client

• Sending mail as an SMTP client and receiving mail as an IMAP client

• Sending mail as an SMTP client and receiving mail as an SMTP server

• Sending mail as an SMTP server and receiving mail as an SMTP server

The first two are useful if you rely completely on your ISP's SMTP and POP or IMAP email services. The third example is a mixed approach, relaying outgoing mail through your ISP's SMTP mail server, but receiving mail directly through your local SMTP server. The fourth approach supports running your own complete, independent mail server for both outgoing and incoming mail.

SENDING MAIL AS AN SMTP CLIENT AND RECEIVING MAIL AS A POP CLIENT

If you are sending mail as an SMTP client and are receiving mail as a POP client, you are relying completely on a remote site for your mail services. The remote site hosts both an SMTP server for relaying your outgoing mail and a POP server for local mail retrieval:

 SMTP_GATEWAY="my.isp.server"          # external mail server or relay           if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \             -s $IPADDR --sport $UNPRIVPORTS \             -d $SMTP_GATEWAY --dport 25 -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          -d $SMTP_GATEWAY --dport 25 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          -s $SMTP_GATEWAY --sport 25 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT POP_SERVER="my.isp.pop.server"        # external pop server, if any if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \              -s $IPADDR --sport $UNPRIVPORTS \              -d $POP_SERVER --dport 110 -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          -d $POP_SERVER --dport 110 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          -s $POP_SERVER --sport 110 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT 

SENDING MAIL AS AN SMTP CLIENT AND RECEIVING MAIL AS AN IMAP CLIENT

If you are sending mail as an SMTP client and are receiving mail as an IMAP client, you are relying completely on a remote site for your mail services. The remote site hosts both an SMTP server for relaying outgoing mail and an IMAP server for local mail retrieval:

 SMTP_GATEWAY="my.isp.server"          # external mail server or relay if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \             -s $IPADDR --sport $UNPRIVPORTS \             -d $SMTP_GATEWAY --dport 25 -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          -d $SMTP_GATEWAY --dport 25 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          -s $SMTP_GATEWAY --sport 25 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT IMAP_SERVER="my.isp.imap.server"       # external imap server, if any if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \              -s $IPADDR --sport $UNPRIVPORTS \              -d $IMAP_SERVER --dport 143 -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          -d $IMAP_SERVER --dport 143 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          -s $IMAP_SERVER --sport 143 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT 

SENDING MAIL AS AN SMTP CLIENT AND RECEIVING MAIL AS AN SMTP SERVER

If you are sending mail as an SMTP client and are receiving mail as an SMTP server, you are relying on a remote site to offer SMTP service to relay your outgoing mail to remote destinations. You run sendmail locally as a local SMTP server, allowing remote hosts to send mail to your machine directly. Outgoing mail is relayed through your ISP, but the local sendmail daemon knows how to deliver incoming mail to local user accounts:

 SMTP_GATEWAY="my.isp.server"           # external mail server or relay if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \             -s $IPADDR --sport $UNPRIVPORTS \             -d $SMTP_GATEWAY --dport 25 -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          -d $SMTP_GATEWAY --dport 25 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          -s $SMTP_GATEWAY --sport 25 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A INPUT  -i $INTERNET -p tcp \              --sport $UNPRIVPORTS \              -d $IPADDR --dport 25 \              -m state --state NEW -j ACCEPT fi $IPT -A INPUT  -i $INTERNET -p tcp \          --sport $UNPRIVPORTS \          -d $IPADDR --dport 25 -j ACCEPT $IPT -A OUTPUT -o $INTERNET -p tcp ! --syn \          -s $IPADDR --sport 25 \          --dport $UNPRIVPORTS -j ACCEPT 

SENDING MAIL AS AN SMTP SERVER AND RECEIVING MAIL AS AN SMTP SERVER

If you are sending mail as an SMTP server and are receiving mail as an SMTP server, you provide all your own mail services. Your local sendmail daemon is configured to relay outgoing mail to the destination hosts itself, as well as collect and deliver incoming mail:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \              -s $IPADDR --sport $UNPRIVPORTS \              --dport 25 -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          --dport 25 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          --sport 25 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A INPUT  -i $INTERNET -p tcp \              --sport $UNPRIVPORTS \              -d $IPADDR --dport 25 \              -m state --state NEW -j ACCEPT fi $IPT -A INPUT  -i $INTERNET -p tcp \          --sport $UNPRIVPORTS \          -d $IPADDR --dport 25 -j ACCEPT $IPT -A OUTPUT -o $INTERNET -p tcp ! --syn \          -s $IPADDR --sport 25 \          --dport $UNPRIVPORTS -j ACCEPT 

HOSTING A MAIL SERVER FOR REMOTE CLIENTS

Hosting public POP or IMAP services is unusual for a small system. You might do this if you offer remote mail services to a few friends, for example, or if their ISP mail service is temporarily unavailable. In any case, it's important to limit the clients your system will accept connections from, both on the packet-filtering level and on the server configuration level.

HOSTING A POP SERVER FOR REMOTE CLIENTS

POP servers are one of the most common and successful points of entry for hacking exploits. Firewall rules can offer some amount of protection, in many cases. Of course, you would limit access at the server configuration level as well. As always, and perhaps particularly so with mail server software, it is crucial to keep up-to-date with security updates for the software.

If you use a local system as a central mail server and run a local POP3 server to provide mail access to local machines on a LAN, you don't need the server rules in this example. Incoming connections from the Internet should be dropped. If you do need to host POP service for a limited number of remote individuals, the next two rules allow incoming connections to your POP server. Connections are limited to your specific clients' IP addresses:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A INPUT  -i $INTERNET -p tcp \              -s <my.pop.clients> --sport $UNPRIVPORTS \              -d $IPADDR --dport 110 \              -m state --state NEW -j ACCEPT fi $IPT -A INPUT  -i $INTERNET -p tcp \          -s <my.pop.clients> --sport $UNPRIVPORTS \          -d $IPADDR --dport 110 -j ACCEPT $IPT -A OUTPUT -o $INTERNET -p tcp ! --syn \          -s $IPADDR --sport 110 \          -d <my.pop.clients> --dport $UNPRIVPORTS -j ACCEPT 

If your site were an ISP, you could use network address masking to limit which source addresses you would accept POP connection requests from:

 POP_CLIENTS="192.168.24.0/24" 

If yours is a residential site with a handful of remote POP clients, the client addresses would need to be stated explicitly, with a separate rule pair for each client address.

HOSTING AN IMAP SERVER FOR REMOTE CLIENTS

IMAP servers are one of the most common and successful points of entry for hacking exploits. Firewall rules can offer some amount of protection, in many cases. Of course, you would limit access at the server configuration level as well. As always, and perhaps particularly so with mail server software, it is crucial to keep up-to-date with security updates for the software.

If you use a local system as a central mail server and run a local imapd server to provide mail access to local machines on a LAN, you don't need a server rule. Incoming connections from the Internet should be dropped. If you do need to host IMAP service for a limited number of remote individuals, the next two rules allow incoming connections to your IMAP server. Connections are limited to your specific clients' IP addresses:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A INPUT  -i $INTERNET -p tcp \              -s <my.imap.clients> --sport $UNPRIVPORTS \              -d $IPADDR --dport 143 \              -m state --state NEW -j ACCEPT fi $IPT -A INPUT  -i $INTERNET -p tcp \          -s <my.imap.clients> --sport $UNPRIVPORTS \          -d $IPADDR --dport 143 -j ACCEPT $IPT -A OUTPUT -o $INTERNET -p tcp ! --syn \          -s $IPADDR --sport 143 \          -d <my.imap.clients> --dport $UNPRIVPORTS -j ACCEPT 

If your site were an ISP, you could use network address masking to limit which source addresses you would accept IMAP connection requests from:

 IMAP_CLIENTS="192.168.24.0/24" 

If yours is a residential site with a handful of remote IMAP clients, the client addresses would need to be stated explicitly, with a separate rule pair for each client address.

Accessing Usenet News Services (TCP NNTP Port 119)

Usenet news is accessed over NNTP running on top of TCP through service port 119. Reading news and posting articles are handled by your local news client. Few systems require the server rules. Table 4.4 lists the complete client/server connection protocol for the NNTP Usenet news service.

Table 4.4. NNTP Protocol

DESCRIPTION	PROTOCOL	REMOTE ADDRESS	REMOTE PORT	IN/OUT	LOCAL ADDRESS	LOCAL PORT	TCP FLAG
Local client query	TCP	NEWS SERVER	119	Out	IPADDR	1024:65535	Any
Remote server response	TCP	NEWS SERVER	119	In	IPADDR	1024:65535	ACK
Remote client query	TCP	NNTP clients	1024:65535	In	IPADDR	119	Any
Local server response	TCP	NNTP clients	1024:65535	Out	IPADDR	119	ACK
Local server query	TCP	News feed	119	Out	IPADDR	1024:65535	Any
Remote server response	TCP	News feed	119	In	IPADDR	1024:65535	ACK

READING AND POSTING NEWS AS A USENET CLIENT

The client rules allow connections to your ISP's news server. Both reading news and posting articles are handled by these rules:

 NEWS_SERVER="my.news.server"           # external news server, if any if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \             -s $IPADDR --sport $UNPRIVPORTS \             -d $NEWS_SERVER --dport 119 -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          -d $NEWS_SERVER --dport 119 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          -s $NEWS_SERVER --sport 119 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT 

HOSTING A USENET NEWS SERVER FOR REMOTE CLIENTS

A small site is very unlikely to host a news server for the outside world. Even hosting a local news server is unlikely. For the rare exception, the server rules should be configured to allow incoming connections from only a select set of clients:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A INPUT  -i $INTERNET -p tcp \              -s <my.news.clients> --sport $UNPRIVPORTS \              -d $IPADDR --dport 119 \              -m state --state NEW -j ACCEPT fi $IPT -A INPUT  -i $INTERNET -p tcp \          -s <my.news.clients> --sport $UNPRIVPORTS \          -d $IPADDR --dport 119 -j ACCEPT $IPT -A OUTPUT -o $INTERNET -p tcp ! --syn \          -s $IPADDR --sport 119 \          -d <my.news.clients> --dport $UNPRIVPORTS -j ACCEPT 

ALLOWING PEER NEWS FEEDS FOR A LOCAL USENET SERVER

A small, home-based site is unlikely to have a peer-to-peer news-feed server relationship with an ISP. Although news servers used to be fairly accessible to the general Internet, few open news servers are available anymore because of SPAM and server load issues.

If your site is large enough or rich enough to host a general Usenet server, you have to get your news feed from somewhere. The next two rules allow your local news server to receive its news feed from a remote server. The local server contacts the remote server as a client. The only difference between the peer-to-peer news-feed rules and the regular client rules is the name or address of the remote host:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \           -s $IPADDR --sport $UNPRIVPORTS \           -d <my.news.feed> --dport 119 -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          -d <my.news.feed> --dport 119 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          -s <my.news.feed> --sport 119 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT 

Telnet (TCP Port 23)

Telnet had been the de facto standard means of remote login over the Internet for many years. As the nature of the Internet community has changed, telnet has come to be viewed more as an insecure service because it communicates in ASCII clear text. If you have the option, you should always use an encrypted service, such as SSH, rather than telnet. However, Microsoft Windows does not offer an SSH service and only offers telnetso much for that security commitment!

The client and server rules here allow access to and from anywhere. If you use telnet, you can probably limit the external addresses to a very select subset at the packet-filtering level. Table 4.5 lists the complete client/server connection protocol for the telnet service.

Table 4.5. Telnet Protocol

DESCRIPTION	PROTOCOL	REMOTE ADDRESS	REMOTE PORT	IN/OUT	LOCAL ADDRESS	LOCAL PORT	TCP FLAG
Local client request	TCP	ANYWHERE	23	Out	IPADDR	1024:65535	Any
Remote server response	TCP	ANYWHERE	23	In	IPADDR	1024:65535	ACK
Remote client TCP request		Telnet clients	1024:65535	In	IPADDR	23	Any
Local server response	TCP	Telnet clients	1024:65535	Out	IPADDR	23	ACK

ALLOWING OUTGOING CLIENT ACCESS TO REMOTE SITES

If you need to use telnet to access remote systems (SSH servers are very prevalent today), the next two rules allow outgoing connections to remote sites. If your site has multiple users, you should limit outgoing connections to the specific sites your users have accounts on, if at all possible, rather than allowing outgoing connections to anywhere:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \              -s $IPADDR --sport $UNPRIVPORTS \              --dport 23 -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          --dport 23 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          --sport 23 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT 

ALLOWING INCOMING ACCESS TO YOUR LOCAL SERVER

Even if you need client access to remote servers, you may not need to allow incoming connections to your telnet server. If you do, the next two rules allow incoming connections to your server:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A INPUT  -i $INTERNET -p tcp \              --sport $UNPRIVPORTS \              -d $IPADDR --dport 23 \              -m state --state NEW -j ACCEPT fi $IPT -A INPUT  -i $INTERNET -p tcp \          --sport $UNPRIVPORTS \          -d $IPADDR --dport 23 -j ACCEPT $IPT -A OUTPUT -o $INTERNET -p tcp ! --syn \          -s $IPADDR --sport 23 \          --dport $UNPRIVPORTS -j ACCEPT 

Rather than allowing connections from anywhere, it is far preferable to define server rules for each specific host or network that an incoming connection can legitimately originate from. SSH clients are freely available for almost all systems in use today.

SSH (TCP Port 22)

With the expiration of the RSA patent in year 2000, OpenSSH, secure shell, is included in Linux distributions. It is also freely available from software sites on the Internet. SSH is considered far preferable to using telnet for remote login access because both ends of the connection use authentication keys for both hosts and users, and because data is encrypted. Additionally, SSH is more than a remote login service. It can automatically direct X Window connections between remote sites, and FTP and other TCP-based connections can be directed over the more secure SSH connection. Provided that the other end of the connection allows SSH connections, it's possible to route all TCP connections through the firewall using SSH. As such, SSH is something of a poor man's virtual private network (VPN).

The ports used by SSH are highly configurable. By default, connections are initiated between a client's unprivileged port and the server's assigned service port 22. The SSH client uses the unprivileged ports exclusively. The rules in this example apply to the default SSH port usage:

 SSH_PORTS="1024:65535"               # RSA authentication 

or

 SSH_PORTS="1020:65535"               # Rhost authentication 

The client and server rules here allow access to and from anywhere. In practice, you would limit the external addresses to a select subset, particularly because both ends of the connection must be configured to recognize each individual user account for authentication. Table 4.6 lists the complete client/server connection protocol for the SSH service.

Table 4.6. SSH Protocol

DESCRIPTION	PROTOCOL	REMOTE ADDRESS	REMOTE PORT	IN/OUT	LOCAL ADDRESS	LOCAL PORT	TCP FLAG
Local client request	TCP	ANYWHERE	22	Out	IPADDR	1024:65535	Any
Remote server request	TCP	ANYWHERE	22	In	IPADDR	1024:65535	ACK
Local client	TCP	ANYWHERE	22	Out	IPADDR	513:1023	Any
Remote server response	TCP	ANYWHERE	22	In	IPADDR	513:1023	ACK
Remote client request	TCP	SSH clients	1024:65535	In	IPADDR	22	Any
Local server response	TCP	SSH clients	1024:65535	Out	IPADDR	22	ACK
Remote client request	TCP	SSH clients	513:1023	In	IPADDR	22	Any
Local server response	TCP	SSH clients	513:1023	Out	IPADDR	22	ACK

ALLOWING CLIENT ACCESS TO REMOTE SSH SERVERS

These rules allow you to connect to remote sites using SSH:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \              -s $IPADDR --sport $SSH_PORTS \              --dport 22 -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $SSH_PORTS \          --dport 22 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          --sport 22 \          -d $IPADDR --dport $SSH_PORTS -j ACCEPT 

ALLOWING REMOTE CLIENT ACCESS TO YOUR LOCAL SSH SERVER

These rules allow incoming connections to your SSH server:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A INPUT  -i $INTERNET -p tcp \              --sport $SSH_PORTS \              -d $IPADDR --dport 22 \              -m state --state NEW -j ACCEPT fi $IPT -A INPUT  -i $INTERNET -p tcp \          --sport $SSH_PORTS \          -d $IPADDR --dport 22 -j ACCEPT $IPT -A OUTPUT -o $INTERNET -p tcp ! --syn \          -s $IPADDR --sport 22 \          --dport $SSH_PORTS -j ACCEPT 

FTP (TCP Ports 21, 20)

FTP remains one of the most common means of transferring files between two networked machines. Web-based browser interfaces to FTP have become common as well. Like telnet, FTP sends both authentication credentials and data communication in plain text over the network. Therefore, FTP is also considered to be an inherently insecure protocol. SFTP and SCP offer improvements to FTP in this regard.

FTP is used as the classic example of a protocol that isn't firewall- or NAT-friendly. Traditional client/server applications that communicate over TCP all work the same way. The client initiates the request to connect to the server.

Table 4.7 lists the complete client/server connection protocol for the FTP service.

Table 4.7. FTP Protocol

DESCRIPTION	PROTOCOL	REMOTE ADDRESS	REMOTE PORT	IN/OUT	LOCAL ADDRESS	LOCAL PORT	TCP FLAG
Local client query	TCP	ANYWHERE	21	Out	IPADDR	1024:65535	Any
Remote server response	TCP	ANYWHERE	21	In	IPADDR	1024:65535	ACK
Remote server port data channel request	TCP	ANYWHERE	20	In	IPADDR	1024:65535	Any
Local client port data channel response	TCP	ANYWHERE	20	Out	IPADDR	1024:65535	ACK
Local client passive data channel request	TCP	ANYWHERE	1024:65535	Out	IPADDR	1024:65535	Any
Remote server passive data channel response	TCP	ANYWHERE	1024:65535	In	IPADDR	1024:65535	ACK
Remote client request	TCP	ANYWHERE	1024:65535	In	IPADDR	21	Any
Local server response	TCP	ANYWHERE	1024:65535	Out	IPADDR	21	ACK
Local server port data channel response	TCP	ANYWHERE	1024:65535	Out	IPADDR	20	Any
Remote client port data channel response	TCP	ANYWHERE	1024:65535	In	IPADDR	20	ACK
Remote client passive data channel request	TCP	ANYWHERE	1024:65535	In	IPADDR	1024:65535	Any
Local server passive data channel response	TCP	ANYWHERE	1024:65535	Out	IPADDR	1024:65535	ACK

FTP deviates from this standard TCP, client/server communication model. FTP relies on two separate connections, one for the control or command stream, and one for passing the data files and other information, such as directory listings. The control stream is carried over a traditional TCP connection. The client binds to a high, unprivileged port, and sends a connection request to the FTP server, which is bound to port 21. This connection is used to pass commands.

In terms of the second data stream connection, FTP has two alternate modes for exchanging data between a client and server: port mode and passive mode. Port mode is the original, default mechanism. The client tells the server which secondary, unprivileged port it will listen on. The server initiates the data connection from port 20 to the unprivileged port the client specified.

This is the deviation from the standard client/server model. The server is initiating the secondary connection back to the client. This is why FTP is a protocol that requires ALG support for both the firewall and NAT. The firewall must account for an incoming connection from port 20 to a local unprivileged port. NAT must account for the destination address used for the secondary data stream connection. (The client has no knowledge that its network traffic is being NATed. The port and address it sent the server were its local, pre-NATed port and address.)

Passive mode is similar to the traditional client/server model in that the client initiates the secondary connection for the data stream. Again, the client initiates the connection from a high, unprivileged port. The server isn't bound to port 20 for the data connection, however. Instead, the server has told the client which high, unprivileged port the client should address the connection request to. The data stream is carried between unprivileged ports on both the client and the server.

In terms of traditional packet filtering, the firewall must allow TCP traffic between all unprivileged ports. Connection state tracking and ALG support allow the firewall to associate the secondary connection with a particular FTP control stream. NAT isn't an issue on the client side because the client is initiating both connections.

ALLOWING OUTGOING CLIENT ACCESS TO REMOTE FTP SERVERS

It's almost a given that most sites will want FTP client access to remote file repositories. Most people will want to enable outgoing client connections to a remote server.

OUTGOING FTP REQUESTS OVER THE CONTROL CHANNEL

The next two rules allow an outgoing control connection to a remote FTP server:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \              -s $IPADDR --sport $UNPRIVPORTS \              --dport 21 -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          --dport 21 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          --sport 21 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT 

PORT-MODE FTP DATA CHANNELS

The next two rules allow the standard data channel connection, in which the remote server calls back to establish the data connection from server port 20 to a client-specified unprivileged port:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A INPUT  -i $INTERNET -p tcp \              --sport 20 \              -d $IPADDR --dport $UNPRIVPORTS \              -m state --state NEW -j ACCEPT fi $IPT -A INPUT  -i $INTERNET -p tcp \          --sport 20 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT $IPT -A OUTPUT -o $INTERNET -p tcp ! --syn \          -s $IPADDR --sport $UNPRIVPORTS \          --dport 20 -j ACCEPT 

This unusual callback behavior, with the remote server establishing the secondary connection with your client, is part of what makes FTP difficult to secure at the packet-filtering level.

PASSIVE-MODE FTP DATA CHANNELS

The next two rules allow the newer passive data channel mode used by most web browsers:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \              -s $IPADDR --sport $UNPRIVPORTS \              --dport $UNPRIVPORTS -m state --state NEW -j ACCEPT fi     $IPT -A OUTPUT -o $INTERNET -p tcp \              -s $IPADDR --sport $UNPRIVPORTS \              --dport $UNPRIVPORTS -j ACCEPT     $IPT -A INPUT -i $INTERNET -p tcp ! --syn \              --sport $UNPRIVPORTS \              -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT 

Passive mode is considered more secure than port mode because the FTP client initiates both the control and the data connections, even though the connection is made between two unprivileged ports. And, as stated earlier, passive mode doesn't have the problems with NAT that port mode does on the client side.

ALLOWING INCOMING ACCESS TO YOUR LOCAL FTP SERVER

Whether to offer FTP services to the world is a difficult decision. Although FTP sites abound on the Internet, FTP server configuration requires great care. Numerous FTP security exploits are possible.

If your goal is to offer general read-only access to some set of files on your machine, you might consider making these files available through a web server. If your goal is to allow file uploads to your machine from the outside, FTP server access should be severely limited on the firewall level, on the xinetd configuration level, on the tcp_wrappers level, and on the FTP configuration level.

In any case, if you decide to offer FTP services, and if you decide to allow incoming file transfers, write access should not be allowed via anonymous FTP. Remote write access to your file systems should be allowed only from specific, authenticated FTP user accounts, from specific remote sites, and to carefully controlled and limited FTP areas reserved in your file system. Hosting the FTP area from a chroot environment would be even better.

INCOMING FTP REQUESTS

The next two rules allow incoming control connections to your FTP server:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A INPUT  -i $INTERNET -p tcp \              --sport $UNPRIVPORTS \              -d $IPADDR --dport 21 \              -m state --state NEW -j ACCEPT fi $IPT -A INPUT  -i $INTERNET -p tcp \          --sport $UNPRIVPORTS \          -d $IPADDR --dport 21 -j ACCEPT $IPT -A OUTPUT -o $INTERNET -p tcp ! --syn \          -s $IPADDR --sport 21 \          --dport $UNPRIVPORTS -j ACCEPT 

PORT-MODE FTP DATA CHANNEL RESPONSES

The next two rules allow the FTP server to call back the remote client and establish the secondary data channel connection:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \              -s $IPADDR --sport 20\              --dport $UNPRIVPORTS -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport 20 \          --dport $UNPRIVPORTS -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          --sport $UNPRIVPORTS \          -d $IPADDR --dport 20 -j ACCEPT 

PASSIVE-MODE FTP DATA CHANNEL RESPONSES

The next two rules allow the remote FTP client to establish the secondary data channel connection with the local server:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A INPUT  -i $INTERNET -p tcp \              --sport $UNPRIVPORTS \              -d $IPADDR --dport $UNPRIVPORTS \              -m state --state NEW -j ACCEPT fi $IPT -A INPUT  -i $INTERNET -p tcp \          --sport $UNPRIVPORTS \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT $IPT -A OUTPUT -o $INTERNET -p tcp ! --syn \          -s $IPADDR --sport $UNPRIVPORTS \          --dport $UNPRIVPORTS -j ACCEPT 

CAUTION

Don't use TFTP on the Internet! TFTP offers a simplified, unauthenticated, UDP version of the FTP service. It is intended for loading boot software into routers and diskless workstations over a local network from trusted hosts. Some people confuse TFTP as an alternative to FTP. Don't use it over the Internet, period. Preferably, don't install TFTP on your system at all.

Web Services

Web services are based on the Hypertext Transfer Protocol (HTTP). Client and server connections use the standard TCP conventions. Several higher-level, special-purpose communication protocols are available in addition to the standard general HTTP access, including secure access over SSL or TLS, and access via an ISP-provided web server proxy. These different access protocols use different service ports.

STANDARD HTTP ACCESS (TCP PORT 80)

In normal use, web services are available over http service port 80. Table 4.8 lists the complete client/server connection protocol for the HTTP web service.

Table 4.8. HTTP Protocol

DESCRIPTION	PROTOCOL	REMOTE ADDRESS	REMOTE PORT	IN/OUT	LOCAL ADDRESS	LOCAL PORT	TCP FLAG
Local client request	TCP	ANYWHERE	80	Out	IPADDR	1024:65535	Any
Remote server response	TCP	ANYWHERE	80	In	IPADDR	1024:65535	ACK
Remote client request	TCP	ANYWHERE	1024:65535	In	IPADDR	80	Any
Local server response	TCP	ANYWHERE	1024:65535	Out	IPADDR	80	ACK

ACCESSING REMOTE WEBSITES AS A CLIENT

It's almost inconceivable in today's world that a home-based site would not want to access the World Wide Web from a web browser. The next two rules allow access to remote web servers:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \              -s $IPADDR --sport $UNPRIVPORTS \              --dport 80 -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          --dport 80 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          --sport 80 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT 

ALLOWING REMOTE ACCESS TO A LOCAL WEB SERVER

If you decide to run a web server of your own and host a public website, the following general server rules allow all typical incoming access to your site. This is all that most people need in order to host a website:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A INPUT  -i $INTERNET -p tcp \              --sport $UNPRIVPORTS \              -d $IPADDR --dport 80 \              -m state --state NEW -j ACCEPT fi $IPT -A INPUT  -i $INTERNET -p tcp \          --sport $UNPRIVPORTS \          -d $IPADDR --dport 80 -j ACCEPT $IPT -A OUTPUT -o $INTERNET -p tcp ! --syn \          -s $IPADDR --sport 80 \          --dport $UNPRIVPORTS -j ACCEPT 

SECURE WEB ACCESS (SSL AND TLS) (TCP PORT 443)

Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are used for secure, encrypted web access. The protocols use TCP port 443. You will most often encounter this if you go to a commercial website to purchase something, use online banking services, or enter a protected web area where you'll be prompted for personal information. The Apache web server shipped with Red Hat Linux 7.1 includes OpenSSL support. Table 4.9 lists the complete client/server connection protocol for the service.

Table 4.9. SSL and TLS Protocol

DESCRIPTION	PROTOCOL	REMOTE ADDRESS	REMOTE PORT	IN/OUT	LOCAL ADDRESS	LOCAL PORT	TCP FLAG
Local client request	TCP	ANYWHERE	443	Out	IPADDR	1024:65535	Any
Remote server response	TCP	ANYWHERE	443	In	IPADDR	1024:65535	ACK
Remote client request	TCP	ANYWHERE	1024:65535	In	IPADDR	443	Any
Local server response	TCP	ANYWHERE	1024:65535	Out	IPADDR	443	ACK

ACCESSING REMOTE WEBSITES OVER SSL OR TLS AS A CLIENT

Most people will want client access to secure websites at some point:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \              -s $IPADDR --sport $UNPRIVPORTS \              --dport 443 -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          --dport 443 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          --sport 443 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT 

ALLOWING REMOTE ACCESS TO A LOCAL SSL OR TLS WEB SERVER

If you conduct some form of e-commerce or have a user-authenticated web area, you'll most likely want to allow incoming connections to encryption-protected areas of your website. Otherwise, you won't need local server rules.

Both the OpenSSL included with Linux and commercial SSL support packages are available for the Apache web server. See http://www.apache.org for more information.

The next two rules allow incoming access to your web server using the SSL or TLS protocols:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A INPUT  -i $INTERNET -p tcp \              --sport $UNPRIVPORTS \              -d $IPADDR --dport 443 \              -m state --state NEW -j ACCEPT fi $IPT -A INPUT  -i $INTERNET -p tcp \          --sport $UNPRIVPORTS \          -d $IPADDR --dport 443 -j ACCEPT $IPT -A OUTPUT -o $INTERNET -p tcp ! --syn \          -s $IPADDR --sport 443 \          --dport $UNPRIVPORTS -j ACCEPT 

WEB PROXY ACCESS (TCP PORTS 8008, 8080)

Publicly accessible web server proxies are most common at ISPs. As a customer, you configure your browser to use a remote proxy service. Web proxies are often accessed through one of two unprivileged ports assigned for this purpose, ports 8008 or 8080, as defined by the ISP. In return, you get faster web page access when the pages are already cached locally at your ISP's server and the relative anonymity of proxied access to remote sites. Your connections are not direct, but instead they are done on your behalf by your ISP's proxy. Table 4.10 lists the complete client/server connection protocol for the web proxy service.

Table 4.10. Web Proxy Protocol

DESCRIPTION	PROTOCOL	REMOTE ADDRESS	REMOTE PORT	IN/OUT	LOCAL ADDRESS	LOCAL PORT	TCP FLAG
Local client request	TCP	WEB PROXY SERVER	WEB PROXY PORT	Out	IPADDR	1024:65535	Any
Remote server response	TCP	WEB PROXY SERVER	WEB PROXY PORT	In	IPADDR	1024:65535	ACK

If you use a web proxy service offered by your ISP, the specific server address and port number will be defined by your ISP. The client rules are as shown here:

 WEB_PROXY_SERVER="my.www.proxy"         # ISP Web proxy server, if any WEB_PROXY_PORT="www.proxy.port"         # ISP Web proxy port, if any                                         # typically 8008 or 8080 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \              -s $IPADDR --sport $UNPRIVPORTS \              -d $WEB_PROXY_SERVER --dport $WEB_PROXY_PORT \              -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          -d $WEB_PROXY_SERVER --dport $WEB_PROXY_PORT -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          -s $WEB_PROXY_SERVER --sport $WEB_PROXY_PORT \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT 

Whois (TCP Port 43)

The whois program accesses the InterNIC Registration Services database. Table 4.11 lists the complete client/server connection protocol for the whois service.

Table 4.11. Whois Protocol

DESCRIPTION	PROTOCOL	REMOTE ADDRESS	REMOTE PORT	IN/OUT	LOCAL ADDRESS	LOCAL PORT	TCP FLAG
Local client request	TCP	ANYWHERE	43	Out	IPADDR	1024:65535	Any
Remote server response	TCP	ANYWHERE	43	In	IPADDR	1024:65535	ACK

The next two rules enable you to query an official remote server:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \              -s $IPADDR --sport $UNPRIVPORTS \              --dport 43 -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          --dport 43 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          --sport 43 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT 

RealAudio, RealVideo, and QuickTime (TCP Ports 554 and 7070)

RealAudio, RealVideo, and QuickTime use the same ports. The control connection to the server is built on top of the Real-Time Streaming Protocol (RTSP). See RFC 2326, "Real Time Streaming Protocol (RTSP)," for more information on the protocol. The incoming data stream is built on top of the Real-Time Transport Protocol (RTP). See RFC 3550, "RTP: A Transport Protocol for Real-Time Applications," for more information on the RTP protocol. See http://www.realnetworks.com for more information on RealAudio and RealVideo firewall requirements.

The client programs can be configured to use TCP solely, to use TCP for the control connection and UDP for the data stream (the UDP port can be configured to be a single port or one from a range of ports), or to use the HTTP application protocol solely. The TCP server ports, 554 or 7070 and 7071, depend on the client and server versions. The UDP client ports range between 6970 and 7170 for newer clients. If your site uses the older RealAudio version 3.0 player, the UDP client port range is 6770 to 7170. The actual port range supported can vary by application and platform.

Typically, the client program uses the most efficient transport combination available. The client determines this by attempting the different methods. Because bidirectional protocols usually have problems getting through a firewall without ALG support, the data stream will usually arrive over the TCP or HTTP protocols.

In other words, without a firewall support module for RealAudio, your options are to use HTTP for the incoming stream, to open the specific TCP or UDP ports and not use the state module (or, at least, not use the INVALID match), or to open the required ports and place the rules for the data stream before the state match rules.

Table 4.12 lists the control and data streams for a local client.

Table 4.12. RealAudio Protocol

DESCRIPTION	PROTOCOL	REMOTE ADDRESS	REMOTE PORT	IN/OUT	LOCAL ADDRESS	LOCAL PORT	TCP FLAG
Local client control request	TCP	ANYWHERE	554,7070	Out	IPADDR	1024:65535	Any
Remote server control response	TCP	ANYWHERE	554,7070	In	IPADDR	1024:65535	ACK
Local client TCP data request	TCP	ANYWHERE	7071	Out	IPADDR	1024:65535	Any
Remote server TCP data response	TCP	ANYWHERE	7071	In	IPADDR	1024:65535	ACK
Remote server UDP data stream	UDP	ANYWHERE	1024:65535	In	IPADDR	6970:71709

The next rule pair establishes the control connection with the server:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \              -m multiport --source-port 554,7070 \              --syn -s $IPADDR --sport $UNPRIVPORTS \              -m state--state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -m multiport --destination-port 554,7070 \          --syn -s $IPADDR --dport $UNPRIVPORTS -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp \          -m multiport --destination-port 554,7070 \          ! --syn -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT 

The next rule allows the preferred incoming UDP data stream from the server:

 $IPT -A INPUT -i $INTERNET -p udp \          --sport $UNPRIVPORTS \          -d $IPADDR --dport 6970:7170 -j ACCEPT 

The next rule pair establishes the TCP data stream connection with the server:

 if [ "$CONNECTION_TRACKING" = "1" ]; then     $IPT -A OUTPUT -o $INTERNET -p tcp \              -s $IPADDR --sport $UNPRIVPORTS \              --dport 7071 -m state --state NEW -j ACCEPT fi $IPT -A OUTPUT -o $INTERNET -p tcp \          -s $IPADDR --sport $UNPRIVPORTS \          --dport 7071 -j ACCEPT $IPT -A INPUT -i $INTERNET -p tcp ! --syn \          --sport 7071 \          -d $IPADDR --dport $UNPRIVPORTS -j ACCEPT