[Courses] [Security] Firewall theory -- FTP and connection tracking

[Raven, corporate courtesan]

Heya --

Quoth coldfire (Mon, Mar 11, 2002 at 07:56:35PM -0500):
> would now be a good time to mention connection tracking and the state
> module?

	Sure!  [grin]  Stateful firewalling is the big difference
between ipchains and iptables.  Ipchains is, essentially, a packet
filter.  You can say "packets of this type, protocol blah, allow from A
to B, block from anywhere to C, drop everything else."  But there's
nothing in there that keeps track of each given request-and-answer
session, end to end.  Iptables provides this capability.
 
> in the above example, ports 1-1024 would be filtered ... anything above
> would be left wide open.  this may not be desirable, as users could
> configure services to run on those higher ports such as ftp and use your
> server for a nice wares site or something ...

	Right.  Things like this are why it's important to have disk
quotas for your users if you're running an FTP server, and to keep an
eye on network and server usage in general.
 
> rather, you can use "Connection Tracking" which is required for IP
> masquerading and NAT (kernel 2.4.x) in conjunction with "Connection state
> match support."  this will give the kernel the ability to make decisions
> based on previous packets ..

	So if it's seen the initial SYN request that initiates the TCP
connection come from inside the network, it keeps track of that port
(source port of that SYN) and allow incoming packets to that port.
FTP is extra annoying this way, though iptables can track its
connections too.  Let's have a quick sidetrack to understand why.

	Unlike most networked services, FTP uses two well-known ports,
20 and 21.  20 is the port for FTP data, and 21 is the port for FTP
control information.  This makes an extra hole you have to leave in your
firewall when you're an FTP server.  But the real problem comes when you
have an FTP client behind a firewall.

FTP Client   -------------|----|-------------> FTP server
10.1.1.10                                      10.1.1.4
port 41327                                     port 21

	The initial connection comes from a high-numbered port on the
client side to the FTP control port, 21.  This is going to be allowed
through most firewalls.  But the problem is the reply.  When you send an
FTP command (ls, get, put, etc.), that opens a whole separate TCP connection
from the server to the client.  This causes a problem -- firewalls may
block THAT connection. 

FTP Client   -------------|----|-------------> FTP server
10.1.1.10                 | fw |               10.1.1.4
port 41327                |  * |-------------  port 20

	(That source port is 21 if it's sending control info, 20 if it's
sending a file.  So, 21 when replying to the initial SYN with SYN, ACK
and that TCP connection.  20 when replying to an ls, get, put, etc.)
But the destination is some port that the FTP client has specified.

	If we have a fairly tight firewall, it's not going to allow just
any box to connect through it on a random high port.  So that ftp-data
connection gets dropped, and the user sees their FTP client fail
immediately after connection (i.e. "as soon as I try to do anything").
This type of FTP is called Active FTP, or Active Mode FTP.  

	Passive mode FTP makes firewalling a lot easier.  The secondary
data connection comes from the client side, and so most firewalls will
allow this.  You can force an FTP client to passive mode using PASV on
the command line for most Linux FTP clients.  GUI clients may have a
"use passive mode" setting somewhere on there.

	Fortunately for us, iptables allows us to track the state of an
FTP connection and specify rules for it with the --state flag.  So you
can permit packets that are part of an already established session with
--state ESTABLISHED, or packets that are part of a new session based on
an old one (as in the case of active FTP) with --state RELATED.

http://www.cs.princeton.edu/~jns/security/iptables/iptables_conntrack.html

will give you an overview of connection tracking in general.  We'll show
lots of examples of this once we finish with theory and start diving
into configurations.

	Thanks, Coldfire!

Cheers,
Raven

"Sed, sed, awk.  Like duck, duck, goose.  Sync, sync, halt.  It's the
 order of nature."
  -- me, after too long a day at work