Next Previous Contents

6. IP protocols and their firewall characteristics

6.1 Standard TCP and UDP protocols

Most of the connections made in tcp/ip follow a standard form. The client machine picks a random port between 1024 and 65535. The packets are sent to a fixed, known port that's below 1024.

For example, I need to send an email message from mybox.office.com to mailserver.office.com. Since email goes to tcp port 25 (see /etc/services for some of these), the tcp/ip code on mybox picks a random tcp port, such as 1931. Packets flow from mybox port 1931 to port 25 on mailserver. Packets also flow back from mailserver port 25 to mybox port 1931.

Here are some of the protocols that follow this form:

6.2 ICMP

ICMP doesn't use source and destination ports, but it has icmp codes and subcodes, each a number between 0 and 15.

6.3 DNS

If the firewall or one of the machines behind it is a DNS server, you have a situation where mason issues a steady flow of DNS requests to resolve the machine names and each DNS request requires a new rule, which in turn requires more DNS requests... ugh.

Mason no longer does DNS lookups on machines involved in DNS lookups. If you have the names and IP addresses of your DNS servers, add them to /etc/hosts.

6.4 FTP

Ahhh, yes, ftp. The scourge of firewall creators everywhere.

If you're using iptables, have the ip_conntrack_ftp module loaded and have uncommented the "-m state --state ESTABLISHED,RELATED" lines in baserules, the problem I'm about to describe does not apply to you. Since iptables is a stateful firewall, this problem has been solved in an elegant and now hassle-free way.

Ftp starts off well because the client opens a connection from a high port (1024-65535) to the ftp control port 21. This part of the connection follows the same model as other tcp protocols: client uses a random high port and connects to a fixed low port.

The problem arises when it's time to actually transmit data. The client and server exchange directory listings and files over additional tcp connections that are between a random high port at the client end and a random high port at the server end.

Remember that packet filtering firewalls depend on being able to identify connections by their (fixed and generally low) server port. Here we have connections that need to be allowed if ftp is going to work, but can't be identified this way.

It really comes down to a choice: does the firewall allow ftp traffic (leaving at least one high to high rule which is a generally considered a security risk), or do we block ftp? You'll need to decide.

Mason creates these rules as transparently as any others. It opens up the ports for the control channel and the high to high rule (called the data channel). A single ftp connection could therefore open 12 rules. You'll need to decide whether these high to high rules are too much of a security risk.

If you do choose to open up ftp rules, you might want to do these last. This allows you to put in more specific rules first.

6.5 Netbios

For those hoping to come here for a simple set of rules for firewalling netbios, sorry. This one is all over the map.

Mason comes in really handy for netbios because it works with whatever netbios throws at it. The netbios ports are 135, 137, 138, and 139 - both tcp and udp. Connections can be from one of these low ports to itself, from a high port to one of these ports, or from a high port to a high port.

In short, good luck trying to do this without Mason.

By the way, allowing netbios traffic in from and out to the Internet may be a very bad idea.

6.6 NTP

NTP is one of the few protocols that uses the same port at both the client and server end. In this case, it is port 123/udp.

6.7 SSH

SSH (server port 22/tcp) has one minor note about its operation. When installed by root (setuid), it may not use a random high port between 1024 and 65535 for the client end. The first client session may use port 1023, the next uses 1022, etc. No real problem for Mason, but you might be surprised at the client ports used.

These client ports should NOT be listed in /etc/services, even though it might seem to make identification easier. The reason is that Mason uses this file to identify _server_ ports in the process of deciding whether to use the ACK flag check.

6.8 Other IP protocols

The other protocols, such as ipip, igmp, ospf, etc (see /etc/protocols), don't use port numbers. For this reason, Mason only creates rules between individual machines for these.


Next Previous Contents