Re: ipfw or ipf w/stateful behavior

• Previous message: michael: "ipfw or ipf w/stateful behavior"
• In reply to: michael: "ipfw or ipf w/stateful behavior"
• Next in thread: michael: "Re: ipfw or ipf w/stateful behavior"
• Reply: michael: "Re: ipfw or ipf w/stateful behavior"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Sun, 3 Aug 2003 16:20:13 +0100
To: michael <michael@nettmail.de>

On Sun, Aug 03, 2003 at 02:41:32PM +0200, michael wrote:

> Now i have made all rules with the setup/established or keep-state flags
> (ipfw) and my ftp-connections are not really stateful. I think
> that these behavior is also so by irc-chat.
>
> Now i wont to know, how must i do to become also an stateful behavior
> for these services, w/o to open the high-ports from the firewall,
> then at the last time i become over and over with portscans from outside,
> and i think this is an security reason.
>
> i don't realy want to open the high-ports on my box.

I take it you're trying to access a remote FTP server, not that you're
hosting a FTP server at your site? Securing things for an FTP client
is rather easier than for an FTP server, especially if you've got a
NAT gateway in between.

The problem with FTP is that it is one of the oldest designs of any of
the commonly used networking protocols, and it suffers from a number
of flaws not found in more modern protocols like HTTP. In the days
when it was first designed and implemented, the concept of
automatically using a packet filtering firewall to protect servers and
clients really hadn't yet achieved any real credence. Consequently
the designers felt free to do things like require two connections
between the client and the server: one channel for data and the other
for control messages. See the first part of
http://www.faqs.org/rfcs/rfc959.html (1985) for a potted history of
the protocol.

Traditionally the way an FTP session has been set up is:

     i) Client connects to port 21 (ftp control) on the server. This
        establishes the control channel, which is used throughout the
        session. The client side port is just an arbitrary
        high-numbered port as used for any outgoing connection.

    ii) Client can issue various FTP protocol commands however, as
        soon as a command is sent that requires data to be returned
        (eg. asking for a directory listing) or if a file has to be
        transferred in either direction, then the client sends a PORT
        command to the server, which tells the server to open up a
        data connection typically from port 20 (ftp-data) on the
        server end to the given port number on the client. This can
        happen several times during an FTP session, if more than one
        file is transferred.

        Under FreeBSD the client side port number will be bounded by
        the port numbers given in the net.inet.ip.portrange.hifirst
        and net.inet.ip.portrange.hilast sysctls, which will usually
        be something like 49152 -- 65535, but see the 'restrict'
        command in ftp(1).

Now, this is somewhat horrifying to the modern client-side network
administrators: either you've got to install a protocol aware
firewall, that can detect the outgoing PORT command (with all the
pitfalls that entails) and poke just the right hole in the firewall to
allow the incoming data connection or you've got to bite the bullet
and let external systems make arbitrary incoming connections to the
high port range of your systems. As far as I know, there isn't a FTP
protocol aware firewall implementation freely available for FreeBSD
(although Checkpoint FW-1 is a commercial product that can do that so
of thing, but the closest it gets to running on FreeBSD is when it's
sold as part of a Nokia firewall appliance: those have an OS called
IPSO which is apparently based on FreeBSD 2.x or 3.x)

Instead, and pretty much standard nowadays, an FTP client will use
passive-mode FTP. All web browsers, when told to retrieve a ftp://
URL will automatically use passive ftp. Under FreeBSD, you can set
FTP_PASSIVE_MODE in the environment and the bundled ftp(1) and
fetch(1) FTP clients will then assume passive mode, or you can use the
ftp(1) 'passive' command within an FTP session to toggle passive mode
on or off.

In this case the sequence of events is:

     i) Client connects to port 21 on the server, as before.

    ii) Now, when it is necessary to open up the data channel, the
        client sends the server a PASV command, to which the server
        replies with a suitable port number that the client can open a
        connection to. This time it's the server that uses a port in
        the 49152..65535 range (although see the documentation of the
        -U option in ftpd(8) for ways to modify that, and the client
        end generally uses some arbitrary port as for any outgoing
        connection.

Here both connections are opened by the client onto the server, which
is much more friendly to the client side firewall. You can just write
a rule (stateful or not, as you choose) to permit outgoing connections
-- either to the high range ports, or more generally to any port:

    ipfw add allow tcp from ${myip} to any 49152-65535 keep-state out xmit ${oif}

(omit the 49152-65535 part if you want to allow all outgoing
connections. ${myip} is your local IP address range, and ${oif} is
the outward facing ethernet interface on your firewall: eg. fxp0, rl1)

Note that people that run FTP servers would generally prefer to use
the original PORT style, rather than PASV so that they in their turn
could write nice tight firewall rules. However, as that would prevent
most clients accessing their FTP archives they pretty well have to
provide PASV support.

> give it an chance by using ipf and not ipfw??

Either ipfw(8) or ipf(8) should be able to do the job for you:
functionally the two are quite similar but the configuration syntax is
fairly different.
 
> i have read the documentations, and i have no hint found
> that solve this problem, my i have seen that in first time
> ipf is mutch more complex to configure and has more pitfalls
> to make mistakes, with the ip packet description language.

Stick with what suits you the best.

        Cheers,

        Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
                                                      Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey         Marlow
Tel: +44 1628 476614                                  Bucks., SL7 1TH UK

• application/pgp-signature attachment: stored

• Previous message: michael: "ipfw or ipf w/stateful behavior"
• In reply to: michael: "ipfw or ipf w/stateful behavior"
• Next in thread: michael: "Re: ipfw or ipf w/stateful behavior"
• Reply: michael: "Re: ipfw or ipf w/stateful behavior"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]