From owner-freebsd-security@FreeBSD.ORG Sun Aug 3 08:20:27 2003 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B61D137B401 for ; Sun, 3 Aug 2003 08:20:27 -0700 (PDT) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.2.69.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2526B43FAF for ; Sun, 3 Aug 2003 08:20:26 -0700 (PDT) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost [127.0.0.1]) h73FKEcU013285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Aug 2003 16:20:18 +0100 (BST) (envelope-from matthew@happy-idiot-talk.infracaninophile.co.uk) Received: (from matthew@localhost)h73FKEXF013284; Sun, 3 Aug 2003 16:20:14 +0100 (BST) (envelope-from matthew) Date: Sun, 3 Aug 2003 16:20:13 +0100 From: Matthew Seaman To: michael Message-ID: <20030803152013.GA12709@happy-idiot-talk.infracaninophile.co.uk> Mail-Followup-To: michael , freebsd-security@freebsd.org References: <1059914492.3f2d02fc3de14@mx5.internett.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <1059914492.3f2d02fc3de14@mx5.internett.de> User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-8.6 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-security@freebsd.org Subject: Re: ipfw or ipf w/stateful behavior X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2003 15:20:28 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. >=20 > 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. =20 =20 > 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 --=20 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 --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/LSgtdtESqEQa7a0RAoI/AJ9El9ssMDgJTs9scZqqykdtOfgOGwCcD9pY LnvxutiRjz5HNkQYm+btrhE= =vMRm -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S--