/usr/share/doc/mason/mason-6.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
 <TITLE>The Mason HOWTO: IP protocols and their firewall characteristics</TITLE>
 <LINK HREF="mason-7.html" REL=next>
 <LINK HREF="mason-5.html" REL=previous>
 <LINK HREF="mason.html#toc6" REL=contents>
</HEAD>
<BODY>
<A HREF="mason-7.html"><IMG SRC="next.gif" ALT="Next"></A>
<A HREF="mason-5.html"><IMG SRC="prev.gif" ALT="Previous"></A>
<A HREF="mason.html#toc6"><IMG SRC="toc.gif" ALT="Contents"></A>
<HR>
<H2><A NAME="s6">6. IP protocols and their firewall characteristics</A></H2>

<H2><A NAME="ss6.1">6.1 Standard TCP and UDP protocols</A>
</H2>

<P>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.
<P>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 <EM>back</EM> from mailserver port 25 to mybox port 1931.
<P>Here are some of the protocols that follow this form:
<UL>
<LI>23/TCP - telnet</LI>
<LI>25/TCP - SMTP</LI>
<LI>80/TCP - HTTP</LI>
<LI>110/TCP - POP3</LI>
<LI>143/TCP - IMAP</LI>
<LI>512/UDP - BIFF</LI>
</UL>
<P>
<H2><A NAME="ss6.2">6.2 ICMP</A>
</H2>

<P>     ICMP doesn't use source and destination ports, but it has icmp codes and 
subcodes, each a number between 0 and 15.
<P>
<H2><A NAME="ss6.3">6.3 DNS</A>
</H2>

<P>     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.
<P>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.
<P>
<H2><A NAME="ss6.4">6.4 FTP</A>
</H2>

<P>     Ahhh, yes, ftp.  The scourge of firewall creators everywhere.  
<P>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.
<P>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. 
<P>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.
<P>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. 
<P>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. 
<P>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. 
<P>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.
<P>
<H2><A NAME="ss6.5">6.5 Netbios</A>
</H2>

<P>For those hoping to come here for a simple set of rules for 
firewalling netbios, sorry. This one is all over the map.
<P>Mason comes in <EM>really</EM> 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.
<P>In short, good luck trying to do this <EM>without</EM> Mason.
<P>By the way, allowing netbios traffic in from and out to the
Internet may be a very bad idea.
<P>
<H2><A NAME="ss6.6">6.6 NTP</A>
</H2>

<P>     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.
<P>
<H2><A NAME="ss6.7">6.7 SSH</A>
</H2>

<P>     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. 
<P>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.
<P>
<H2><A NAME="ss6.8">6.8 Other IP protocols</A>
</H2>

<P>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.
<P>
<HR>
<A HREF="mason-7.html"><IMG SRC="next.gif" ALT="Next"></A>
<A HREF="mason-5.html"><IMG SRC="prev.gif" ALT="Previous"></A>
<A HREF="mason.html#toc6"><IMG SRC="toc.gif" ALT="Contents"></A>
</BODY>
</HTML>
mason 1.0.0-12.3 / usr / share / doc / mason / mason-6.html
