> 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 21The 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.
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.
Copyright (c) 2002 by Raven Alder. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/).