On Mon, Oct 24, 2005 at 06:14:49PM +0930, Aluminium Oxide wrote: > which would define a rule which listens to requests from $client_hosts > addressed to $dest_server on port 20 (and 21), and (1) listens for the > packet from the client requesting a port, and then (2) reads from the > contents of the packet in the response to the client specifying which > port it has chosen for the client to connect to for the data transfer.
Just one thing to consider. You can't assume the port request can be conveniently extracted from a single packet's payload. The payload may be split into multiple packets, at arbitrary boundaries into arbitrarily sized chunks. You have to expect bugs and attacks, so TCP segments might arrive out of order and they may overlap (even with contradicting data in the overlaps). I suggest you look up how the in-kernel ftp proxy of ipfilter recently[1] had problems with this. In short, an attacker would elicit a reply from the ftp server in order to manipulate the firewall and get a connection through (for example, send 'HELP foo bar' to elicit the response 'UNKNOWN COMMAND: foo bar'). Then the attacker only ACKnowledges the reply partially, to trigger a retransmission of 'foo bar'. If your module simply scans individual packets' payload to search for a magic string, it will be fooled like this. And, no, the fact that it works for most non-malicious cases is not good enough. Daniel [1] http://www.derkeiler.com/Mailing-Lists/Firewall-Wizards/2002-10/0785.html
