From owner-freebsd-ipfw Mon Jun 19 6: 3:35 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from core.pavilion.net (core.pavilion.net [212.74.0.24]) by hub.freebsd.org (Postfix) with ESMTP id 26E5B37B761 for ; Mon, 19 Jun 2000 06:03:29 -0700 (PDT) (envelope-from matt@pavilion.net) Received: (from matt@localhost) by core.pavilion.net (8.9.3/8.8.8) id OAA96108; Mon, 19 Jun 2000 14:03:48 +0100 (BST) (envelope-from matt) Date: Mon, 19 Jun 2000 14:03:48 +0100 From: Matt Spiers To: Andy Dills Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: Hijacking DNS with ipfw Message-ID: <20000619140348.M79276@pavilion.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from andy@xecu.net on Fri, Jun 09, 2000 at 07:01:00PM -0400 X-NCC-RegID: uk.pavilion Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm in a situation where I have customers with various DNS servers > configured. These customers are all behind a FreeBSD (4.0-R) box. The > FreeBSD box is running named (among other things). > > I had thought that this rule would cut it: > > ipfw add 10 fwd 127.0.0.1,53 udp from any to any 53 recv xl1 > > But that just doesn't work. I'm assuming it's because maybe named gets > confused because fwd rules preserve the dest IP (as fwd rules are intended > to be used in transparent cacheing). > Don't know if this is the answer and if it's been mentioned: Are you using higher than BIND 4? BIND 4 always sends queries from port 53 but BIND 8 name servers don't send queries from port 53 as default. To force it you can add: options { query-source * port 53;}; From the O'Reilly DNS&BIND book,3rd ed., p.381 Good luck, Matt. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jun 19 15:25:41 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from rose.niw.com.au (app3022-2.gw.connect.com.au [203.63.119.4]) by hub.freebsd.org (Postfix) with ESMTP id 37FAD37B6C3 for ; Mon, 19 Jun 2000 15:25:28 -0700 (PDT) (envelope-from ian@niw.com.au) Received: by rose.niw.com.au (Postfix, from userid 1000) id 0F76D62D60; Tue, 20 Jun 2000 07:55:03 +0930 (CST) Date: Tue, 20 Jun 2000 07:55:03 +0930 From: Ian West To: freebsd-ipfw@freebsd.org Subject: A couple of possible changes to ipfw.... Message-ID: <20000620075502.I400@rose.niw.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I passed this briefly by Luigi, and the suggestion was to work up a patch and pass it by the ipfw mailing list, so here it is. (two issues are addressed in these patches actually) The first provides another rule option for ipfw allowing a match to be made against the ip_tos byte, which is used also for diffserv. The new option requires the addition of two bytes to the ip_fw structure, the first being a 'mask' byte, the second being a 'match' byte. Operation is very simple, if the ip_tos_mask byte is non-zero, (a zero mask is silly, there is nothing to match afterwards :-), the mask is applied to the ip_tos byte, the result is then compared with the ip_tos_match value. If the result does not match, then we continue on to the next rule. The kernel change for this involves adding 2 bytes to the ip_fw structure, and a single compare statement. The changes to ipfw.c are to allow these values to be set. These changes have been running on a couple of machines locally for a few days now without problems. Testing has been restricted so far to logging packets with low delay set. ipfw add 10 count log ip from any to any tos 0x1f:0x10 This seems to do pretty much what I expected, logging only ntp traffic, and interactive traffic from ssh etc... The second part of this patch is to make ipfw tee work as I believe the origional aim was, to generate a copy of the packet, which is sent to a tee port, but without disrupting normal flow. This appears to work for me, and has been in operation for some time across several hosts. This particular patch has been in operation for about 3 months on various machines. (Both current and stable). Uptime on these machines has been > 90 days. (ie, since rebooting them with the patch applied.) If someone could check/confirm that the htons for length and offset are correct I would appreciate it, it seems to work for me, but I am not sure if my test ap is doing the wrong thing. (ie should the packet come out of the kernel in network order or host order...) The section tagged @@ -1299,8 +1305,20 @@ can be independantly ignored if you do not wish to affect the ipfw tee function. The next change I would like to make, and would be interested to hear feedback on is to define a new 'action' under ipfw which would change the ip tos/ds byte. Use would be very simlar, in that we would have two bytes, the first being a mask, the second being an 'or' value. (In effect, reset/set values). Syntax would be something along the lines of ipfw add 10 tag 0x1f:0x80 tcp from any 23 to any (Which would tag outbound telnet traffic.) Not sure if the 'command' should be 'tag', 'tos', or maybe even 'ds' ?? This is similar in fucntion to the changes that many (if not most) routers allow these days using diffserv policies. It would be useful though to be able to pre-classify traffic for diffserv streams based on (for example) uid. A more specific example is where you have maybe a background update process for a database, which runs periodically, and does large transfers, but with low priority. A rule such as ipfw add 10 tag 0x1f:0x80 tcp from any to any uid database (This is untested, I have not yet done the patches for tagging packets) should in effect allow traffic for this process to be handled on a gateway box (or even a router) using diffserv with no knowledge of the protocol or application. (Enough waffle, hopefully the idea is clear enough ;-) The down side of this is it does involve 'changing' packets. Which I believe will involve recalculating at least header checksums. I am not yet sure of the impact on stuff like ipsec auth etc... This is stuff I will need to test. Can anybody see any good reason NOT to do this ? Otherwise I will go ahead and work on it, and post patches for review once I have something working. Thanks to all who read this :-) Regards, Ian West Index: sbin/ipfw/ipfw.c =================================================================== RCS file: /cvs/freebsd/src/sbin/ipfw/ipfw.c,v retrieving revision 1.86 diff -u -r1.86 ipfw.c --- sbin/ipfw/ipfw.c 2000/06/18 02:48:19 1.86 +++ sbin/ipfw/ipfw.c 2000/06/18 13:17:08 @@ -362,6 +362,10 @@ } } + if (chain->fw_tos_mask) { + printf(" tos %#x:%#x", chain->fw_tos_mask, chain->fw_tos_match); + } + if (chain->fw_flg & IP_FW_F_UID) { struct passwd *pwd = getpwuid(chain->fw_uid); @@ -828,6 +832,7 @@ " src: from [not] {any|ip[{/bits|:mask}]} [{port|port-port},[port],...]\n" " dst: to [not] {any|ip[{/bits|:mask}]} [{port|port-port},[port],...]\n" " extras:\n" +" tos {mask:match}\n" " uid {user id}\n" " gid {group id}\n" " fragment (may not be used with ports or tcpflags)\n" @@ -1800,6 +1805,26 @@ if (grp == NULL) show_usage("gid \"%s\" is nonexistant", *av); rule.fw_gid = grp->gr_gid; + ac--; av++; + continue; + } + /* For the moment, we will accept either tos or ds as commands */ + if (!strncmp(*av,"tos",strlen(*av)) || !strncmp(*av,"ds",strlen(*av))) { + char *end; + unsigned int mask,match; + mask=match=0; + ac--; av++; + if (!ac) + show_usage("``tos'' requires arguments"); + mask = strtoul(*av, &end, 0); + if (*end == ':') + match = strtoul(++end, &end, 0); + else + show_usage("argument to ''tos'' should be mask:match (where mask and match are both numeric)"); + if(*end != '\0') + show_usage("argument to ''tos'' should be mask:match (where mask and match are both numeric)"); + rule.fw_tos_mask=mask; + rule.fw_tos_match=match; ac--; av++; continue; } Index: sys/netinet/ip_fw.c =================================================================== RCS file: /cvs/freebsd/src/sys/netinet/ip_fw.c,v retrieving revision 1.138 diff -u -r1.138 ip_fw.c --- sys/netinet/ip_fw.c 2000/06/08 15:34:51 1.138 +++ sys/netinet/ip_fw.c 2000/06/18 13:04:24 @@ -914,6 +914,7 @@ struct ip_fw *f = NULL, *rule = NULL; struct ip *ip = *pip; struct ifnet *const rif = (*m)->m_pkthdr.rcvif; + u_char tos = 0; u_short offset = 0 ; u_short src_port = 0, dst_port = 0; struct in_addr src_ip, dst_ip; /* XXX */ @@ -949,6 +950,7 @@ /* * Collect parameters into local variables for faster matching. */ + tos = ip->ip_tos; offset = (ip->ip_off & IP_OFFMASK); { struct tcphdr *tcp; @@ -1108,6 +1110,10 @@ continue; } + /* Check tos/ds byte ONLY if mask is set in this rule */ + if (f->fw_tos_mask && ((tos&f->fw_tos_mask) != f->fw_tos_match)) + continue; + /* Check IP options */ if (f->fw_ipopt != f->fw_ipnopt && !ipopts_match(ip, f)) continue; @@ -1299,8 +1305,20 @@ *cookie = f->fw_number; return(f->fw_divert_port); case IP_FW_F_TEE: - *cookie = f->fw_number; - return(f->fw_divert_port | IP_FW_PORT_TEE_FLAG); + { + struct mbuf *clone; + struct ip *cip; + u_int16_t divert_cookie; + divert_cookie=ip_divert_cookie; + ip_divert_cookie = f->fw_number; + clone=m_dup(*m, M_DONTWAIT); + cip = mtod(clone, struct ip *); + HTONS(cip->ip_len); + HTONS(cip->ip_off); + divert_packet(clone,0,f->fw_divert_port); + ip_divert_cookie=divert_cookie; + } + continue; #endif case IP_FW_F_SKIPTO: /* XXX check */ if ( f->next_rule_ptr ) Index: sys/netinet/ip_fw.h =================================================================== RCS file: /cvs/freebsd/src/sys/netinet/ip_fw.h,v retrieving revision 1.51 diff -u -r1.51 ip_fw.h --- sys/netinet/ip_fw.h 2000/06/08 15:34:51 1.51 +++ sys/netinet/ip_fw.h 2000/06/18 11:47:24 @@ -73,6 +73,7 @@ u_short fu_pipe_nr; /* queue number (option DUMMYNET) */ u_short fu_skipto_rule; /* SKIPTO command rule number */ u_short fu_reject_code; /* REJECT response code */ + u_char fu_ds_mod[2]; /* Mask/Set data pair for tos byte change */ struct sockaddr_in fu_fwd_ip; } fw_un; u_char fw_prot; /* IP protocol */ @@ -82,6 +83,8 @@ * match all ports) */ u_char fw_nports; + u_char fw_tos_mask; /* Mask to apply to tos byte prior to compare */ + u_char fw_tos_match; /* Value to compare against tos byte after mask */ void *pipe_ptr; /* flow_set ptr for dummynet pipe */ void *next_rule_ptr ; /* next rule in case of match */ uid_t fw_uid; /* uid to match */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jun 21 13:50:13 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from hotmail.com (f264.law7.hotmail.com [216.33.236.142]) by hub.freebsd.org (Postfix) with SMTP id 3A1FB37B97E for ; Wed, 21 Jun 2000 13:50:10 -0700 (PDT) (envelope-from pixie_styxx@hotmail.com) Received: (qmail 74342 invoked by uid 0); 21 Jun 2000 20:50:09 -0000 Message-ID: <20000621205009.74341.qmail@hotmail.com> Received: from 64.90.3.2 by www.hotmail.com with HTTP; Wed, 21 Jun 2000 13:50:09 PDT X-Originating-IP: [64.90.3.2] From: "Jennifer Ulrich" To: freebsd-ipfw@FreeBSD.ORG Subject: allowing passive ftp through ipfw Date: Wed, 21 Jun 2000 16:50:09 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello all! I have a FreeBSD 3.4 box which runs ipfw, that is firewalling for a publicly reachable lan of servers, including FTP servers. When I set up the machine, I made the FTP servers reachable by adding a rule for: ipfw add 1400 pass all from x.x.x.x/x to any ipfw add 2300 pass tcp from any to x.x.x.x 21 (x.x.x.x 21 being the address of the ftp server and a default rule allowing anything from my internal lan out through the firewall) I initially had some problems with clients on the lan not being able to establish FTP connections outbound, so I added this rule : ipfw 2300 pass tcp from any to x.x.x.x/x established With these two rules in place, FTP was a happy camper. Users could connect from outside of the network to specific FTP servers, and users inside the network could connect to any FTP server on the internet. Everything ran smoothly until someone from the internet tried to connect to the internal FTP server with Netscape. Apparently, when Netscape opens a FTP connection, it does so by sending a PASV (instead of PORT) command. Basically as I understand it, in passive mode, the server passively sets the port and passes that information to the client. It is then up to the client to actively open the ftp connection on that specified port. So instead of the ftp connection coming in with a destination of 21, it comes in on some predetermined but random high port. (which is why my ruleset denies the connection.) So how do I get passive FTP to work? I certainly would rather not punch a hole in the firewall to allow all traffic destined to the higher ports through to my FTP server. Is there another way to do accomplish this that is a bit more secure? Anyone's thoughts and suggestions regarding this matter, are most appreciated! ~jenn ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jun 21 14:55: 2 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from kestrel.prod.itd.earthlink.net (kestrel.prod.itd.earthlink.net [207.217.121.155]) by hub.freebsd.org (Postfix) with ESMTP id 2DD8137B5F7 for ; Wed, 21 Jun 2000 14:54:57 -0700 (PDT) (envelope-from cjc@earthlink.net) Received: from dialin-client.earthlink.net (pool0821.cvx21-bradley.dialup.earthlink.net [209.179.195.56]) by kestrel.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id OAA16164; Wed, 21 Jun 2000 14:54:54 -0700 (PDT) Received: (from cjc@localhost) by dialin-client.earthlink.net (8.9.3/8.9.3) id OAA00906; Wed, 21 Jun 2000 14:53:26 -0700 (PDT) Date: Wed, 21 Jun 2000 14:52:55 -0700 From: "Crist J. Clark" To: Jennifer Ulrich Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: allowing passive ftp through ipfw Message-ID: <20000621145255.I214@dialin-client.earthlink.net> Reply-To: cjclark@alum.mit.edu References: <20000621205009.74341.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000621205009.74341.qmail@hotmail.com>; from pixie_styxx@hotmail.com on Wed, Jun 21, 2000 at 04:50:09PM -0400 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jun 21, 2000 at 04:50:09PM -0400, Jennifer Ulrich wrote: > Hello all! > > I have a FreeBSD 3.4 box which runs ipfw, that is firewalling for a publicly > reachable lan of servers, including FTP servers. When I set up the machine, > I made the FTP servers reachable by adding a rule for: > > ipfw add 1400 pass all from x.x.x.x/x to any > ipfw add 2300 pass tcp from any to x.x.x.x 21 > (x.x.x.x 21 being the address of the ftp server and a default rule allowing > anything from my internal lan out through the firewall) > > I initially had some problems with clients on the lan not being able to > establish FTP connections outbound, so I added this rule : > > ipfw 2300 pass tcp from any to x.x.x.x/x established [snip] > So how do I get passive FTP to work? I certainly would rather not punch a > hole in the firewall to allow all traffic destined to the higher ports > through to my FTP server. Having a rule like, ipfw add 2350 pass tcp from any 20 to x.x.x.x port_high1-port_high2 Is not really too much of a risk (I don't remember what the range of valid ports is). Make sure you don't have anything you are not comfortable with listening in that range. The rule to allow the initial ftp connection is much, much more risky than the above. > Is there another way to do accomplish this that is > a bit more secure? Actually, this would be a good place for keep-state to work. I'm kinda surprised that no one has added a keep-state method for FTP. It'd just be, ipfw add 2350 pass tcp from any to x.x.x.x 21 setup keep-state ftp Right? Creating a dynamic rule that passes traffic from 20 to x.x.x.x. From how I understand keep-state to work (and it is minimal, sorry), it should not be too difficult to do? -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Jun 22 6:52:50 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id E73FD37C2DC for ; Thu, 22 Jun 2000 06:52:45 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id GAA19824; Thu, 22 Jun 2000 06:51:58 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda19822; Thu Jun 22 06:51:43 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id GAA32957; Thu, 22 Jun 2000 06:51:43 -0700 (PDT) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdB32955; Thu Jun 22 06:51:14 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.10.2/8.9.1) id e5MDpDN05578; Thu, 22 Jun 2000 06:51:13 -0700 (PDT) Message-Id: <200006221351.e5MDpDN05578@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdnA5574; Thu Jun 22 06:50:46 2000 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.0-STABLE X-Sender: cy To: cjclark@alum.mit.edu Cc: Jennifer Ulrich , freebsd-ipfw@FreeBSD.ORG Subject: Re: allowing passive ftp through ipfw In-reply-to: Your message of "Wed, 21 Jun 2000 14:52:55 PDT." <20000621145255.I214@dialin-client.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Jun 2000 06:50:46 -0700 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000621145255.I214@dialin-client.earthlink.net>, "Crist J. Clark" writes: > On Wed, Jun 21, 2000 at 04:50:09PM -0400, Jennifer Ulrich wrote: > > Hello all! > > > > I have a FreeBSD 3.4 box which runs ipfw, that is firewalling for a publicl > y > > reachable lan of servers, including FTP servers. When I set up the machine, > > > I made the FTP servers reachable by adding a rule for: > > > > ipfw add 1400 pass all from x.x.x.x/x to any > > ipfw add 2300 pass tcp from any to x.x.x.x 21 > > (x.x.x.x 21 being the address of the ftp server and a default rule allowin > g > > anything from my internal lan out through the firewall) > > > > I initially had some problems with clients on the lan not being able to > > establish FTP connections outbound, so I added this rule : > > > > ipfw 2300 pass tcp from any to x.x.x.x/x established > > [snip] > > > So how do I get passive FTP to work? I certainly would rather not punch a > > hole in the firewall to allow all traffic destined to the higher ports > > through to my FTP server. > > Having a rule like, > > ipfw add 2350 pass tcp from any 20 to x.x.x.x port_high1-port_high2 > > Is not really too much of a risk (I don't remember what the range of > valid ports is). Make sure you don't have anything you are not > comfortable with listening in that range. The rule to allow the > initial ftp connection is much, much more risky than the above. I vehemently disagree. It is a high risk because an attacker can connect to services running on ports >= 1024, e.g. Oracle. Even if you're not running any services >= 1024, it is trivial to scan your network to get a picture of what it looks like to plan a strategy of attack. IMO too much risk. > > > Is there another way to do accomplish this that is > > a bit more secure? > > Actually, this would be a good place for keep-state to work. I'm kinda > surprised that no one has added a keep-state method for FTP. It'd just > be, > > ipfw add 2350 pass tcp from any to x.x.x.x 21 setup keep-state ftp > > Right? Creating a dynamic rule that passes traffic from 20 to > x.x.x.x. From how I understand keep-state to work (and it is minimal, > sorry), it should not be too difficult to do? Agreed, under IPFW this cannot be done. Ideally this functionality should be in natd. It is possible to use IPFW with ipnat for FTP proxy of IP Filter. Of course that incurs the overhead of two firewalls in your kernel. Not an ideal solution but workable. I think that the FTP protocol, needs to be retired. It is old and not firewall friendly. HTTP can do everything that anonymous FTP can do. To replace regular FTP, use SSH. IMO the only place where the use of FTP is acceptable is within the confines of one's own network. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Jun 22 7:54:38 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from amazhan.bitstream.net (amazhan.bitstream.net [216.243.128.132]) by hub.freebsd.org (Postfix) with SMTP id 9372837B606 for ; Thu, 22 Jun 2000 07:54:35 -0700 (PDT) (envelope-from airboss@bitstream.net) Received: (qmail 17002 invoked by uid 79); 22 Jun 2000 14:54:34 -0000 Received: from dmitri.bitstream.net (206.144.236.191) by mail.bitstream.net with SMTP; 22 Jun 2000 14:54:34 -0000 Date: Thu, 22 Jun 2000 09:59:54 -0500 (CDT) From: Dan Debertin To: freebsd-ipfw@freebsd.org Subject: Re: allowing passive ftp through ipfw In-Reply-To: <200006221351.e5MDpDN05578@cwsys.cwsent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 22 Jun 2000, Cy Schubert - ITSD Open Systems Group wrote: > > I vehemently disagree. It is a high risk because an attacker can > connect to services running on ports >= 1024, e.g. Oracle. Even if > you're not running any services >= 1024, it is trivial to scan your > network to get a picture of what it looks like to plan a strategy of > attack. IMO too much risk. Provided you aren't running services >= 1024, it becomes quite a bit less trivial to scan if you set net.inet.tcp.blackhole=1 net.inet.udp.blackhole=1 > > I think that the FTP protocol, needs to be retired. It is old and not > firewall friendly. HTTP can do everything that anonymous FTP can do. > To replace regular FTP, use SSH. IMO the only place where the use of > FTP is acceptable is within the confines of one's own network. > That would be great if there were reasonably common, well-thought-out clieint software for SCP or SFTP even. The software is there, but compared to the great variety of FTP software out there, and the degree to which it makes FTP easy for the unititiated, asking non-computer-literate people to use SCP is too much. I agree with you on HTTP, though. ~Dan D. -- __________________________________________________________________ -- I am just an advertisement -- For a version -- Of myself. ++ Dan Debertin ++ Senior Systems Administrator ++ Bitstream Underground, LLC ++ airboss@bitstream.net ++ (612)321-9290 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Jun 22 21:41:51 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from kestrel.prod.itd.earthlink.net (kestrel.prod.itd.earthlink.net [207.217.121.155]) by hub.freebsd.org (Postfix) with ESMTP id 11F0637B7D0 for ; Thu, 22 Jun 2000 21:41:48 -0700 (PDT) (envelope-from cjc@earthlink.net) Received: from dialin-client.earthlink.net (pool0729.cvx21-bradley.dialup.earthlink.net [209.179.194.219]) by kestrel.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id VAA05841; Thu, 22 Jun 2000 21:41:44 -0700 (PDT) Received: (from cjc@localhost) by dialin-client.earthlink.net (8.9.3/8.9.3) id VAA00659; Thu, 22 Jun 2000 21:40:17 -0700 (PDT) Date: Thu, 22 Jun 2000 21:39:46 -0700 From: "Crist J. Clark" To: Cy Schubert - ITSD Open Systems Group Cc: Jennifer Ulrich , freebsd-ipfw@FreeBSD.ORG Subject: Re: allowing passive ftp through ipfw Message-ID: <20000622213946.F489@dialin-client.earthlink.net> Reply-To: cjclark@alum.mit.edu References: <20000621145255.I214@dialin-client.earthlink.net> <200006221351.e5MDpDN05578@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200006221351.e5MDpDN05578@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Thu, Jun 22, 2000 at 06:50:46AM -0700 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jun 22, 2000 at 06:50:46AM -0700, Cy Schubert - ITSD Open Systems Group wrote: > In message <20000621145255.I214@dialin-client.earthlink.net>, "Crist J. Clark" writes: > > > > Having a rule like, > > > > ipfw add 2350 pass tcp from any 20 to x.x.x.x port_high1-port_high2 > > > > Is not really too much of a risk (I don't remember what the range of > > valid ports is). Make sure you don't have anything you are not > > comfortable with listening in that range. The rule to allow the > > initial ftp connection is much, much more risky than the above. > > I vehemently disagree. It is a high risk because an attacker can > connect to services running on ports >= 1024, e.g. Oracle. Even if > you're not running any services >= 1024, it is trivial to scan your > network to get a picture of what it looks like to plan a strategy of > attack. IMO too much risk. How can can an attacker scan the network when the high ports are only open for this one host? > > Actually, this would be a good place for keep-state to work. I'm kinda > > surprised that no one has added a keep-state method for FTP. It'd just > > be, > > > > ipfw add 2350 pass tcp from any to x.x.x.x 21 setup keep-state ftp > > > > Right? Creating a dynamic rule that passes traffic from 20 to > > x.x.x.x. From how I understand keep-state to work (and it is minimal, > > sorry), it should not be too difficult to do? > > Agreed, under IPFW this cannot be done. As ipfw(8) is currently implemented? Or is this something that cannot (or should not) be done with ipfw? > Ideally this functionality should be in natd. natd(8) does have some functionality for dealing with ftp. I remember looking over the code a month or two ago... heck if I can remember what it does now. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Jun 22 23:35:17 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id E3DBD37B587 for ; Thu, 22 Jun 2000 23:35:08 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id XAA22604; Thu, 22 Jun 2000 23:34:25 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda22600; Thu Jun 22 23:34:20 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id XAA38283; Thu, 22 Jun 2000 23:34:19 -0700 (PDT) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdo38281; Thu Jun 22 23:33:39 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.10.2/8.9.1) id e5N6Xci97623; Thu, 22 Jun 2000 23:33:38 -0700 (PDT) Message-Id: <200006230633.e5N6Xci97623@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdY97442; Thu Jun 22 23:32:56 2000 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.0-STABLE X-Mailer: nmh 1.0.4, Exmh 2.1.1 X-Sender: cy To: cjclark@alum.mit.edu Cc: Cy Schubert - ITSD Open Systems Group , Jennifer Ulrich , freebsd-ipfw@FreeBSD.ORG Subject: Re: allowing passive ftp through ipfw In-reply-to: Your message of "Thu, 22 Jun 2000 21:39:46 PDT." <20000622213946.F489@dialin-client.earthlink.net> Date: Thu, 22 Jun 2000 23:32:55 -0700 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000622213946.F489@dialin-client.earthlink.net>, "Crist J. Clark" writes: > On Thu, Jun 22, 2000 at 06:50:46AM -0700, Cy Schubert - ITSD Open Systems Gro > up wrote: > > In message <20000621145255.I214@dialin-client.earthlink.net>, "Crist J. Cl > ark" writes: > > > > > > Having a rule like, > > > > > > ipfw add 2350 pass tcp from any 20 to x.x.x.x port_high1-port_high2 > > > > > > Is not really too much of a risk (I don't remember what the range of > > > valid ports is). Make sure you don't have anything you are not > > > comfortable with listening in that range. The rule to allow the > > > initial ftp connection is much, much more risky than the above. > > > > I vehemently disagree. It is a high risk because an attacker can > > connect to services running on ports >= 1024, e.g. Oracle. Even if > > you're not running any services >= 1024, it is trivial to scan your > > network to get a picture of what it looks like to plan a strategy of > > attack. IMO too much risk. > > How can can an attacker scan the network when the high ports are only > open for this one host? An attacker won't be able to scan the low ports but will be able to determine which IP addresses (hosts) are on the inside. If an attacker scans ports >= 1024 he'll easily discover services running on those ports. Think about it: ipfw add allow tcp from any 20 to any 1024-65535 in allows port 20 to initiate connects to any non-privileged port on your network like X and some Kerberos services. > > > > Actually, this would be a good place for keep-state to work. I'm kinda > > > surprised that no one has added a keep-state method for FTP. It'd just > > > be, > > > > > > ipfw add 2350 pass tcp from any to x.x.x.x 21 setup keep-state ftp > > > > > > Right? Creating a dynamic rule that passes traffic from 20 to > > > x.x.x.x. From how I understand keep-state to work (and it is minimal, > > > sorry), it should not be too difficult to do? > > > > Agreed, under IPFW this cannot be done. > > As ipfw(8) is currently implemented? Or is this something that cannot > (or should not) be done with ipfw? IPFW does not support an FTP application proxy, period. Take a look for yourself. > > > Ideally this functionality should be in natd. > > natd(8) does have some functionality for dealing with ftp. I remember > looking over the code a month or two ago... heck if I can remember > what it does now. Just looked at the code myself. Natd supports (client side) passive FTP -- no special code required to do that. To support PORT FTP you need a firewall with an FTP application proxy like IP Filter. IPFW isn't nearly as functional as IP Filter, except for some neat features like divert sockets, custom placement of where the state table can be checked in your ruleset, and its hooks into dummynet. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Jun 23 19:27:52 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from emu.prod.itd.earthlink.net (emu.prod.itd.earthlink.net [207.217.121.31]) by hub.freebsd.org (Postfix) with ESMTP id 4CA4E37BADF for ; Fri, 23 Jun 2000 19:27:48 -0700 (PDT) (envelope-from cjc@earthlink.net) Received: from dialin-client.earthlink.net (pool0278.cvx20-bradley.dialup.earthlink.net [209.179.251.23]) by emu.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id TAA07124; Fri, 23 Jun 2000 19:27:44 -0700 (PDT) Received: (from cjc@localhost) by dialin-client.earthlink.net (8.9.3/8.9.3) id TAA00512; Fri, 23 Jun 2000 19:26:17 -0700 (PDT) Date: Fri, 23 Jun 2000 19:25:46 -0700 From: "Crist J. Clark" To: Cy Schubert - ITSD Open Systems Group Cc: Jennifer Ulrich , freebsd-ipfw@FreeBSD.ORG Subject: Re: allowing passive ftp through ipfw Message-ID: <20000623192546.A481@dialin-client.earthlink.net> Reply-To: cjclark@alum.mit.edu References: <20000622213946.F489@dialin-client.earthlink.net> <200006230633.e5N6Xci97623@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200006230633.e5N6Xci97623@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Thu, Jun 22, 2000 at 11:32:55PM -0700 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jun 22, 2000 at 11:32:55PM -0700, Cy Schubert - ITSD Open Systems Group wrote: > In message <20000622213946.F489@dialin-client.earthlink.net>, "Crist J. Clark" writes: > > On Thu, Jun 22, 2000 at 06:50:46AM -0700, Cy Schubert - ITSD Open Systems Group wrote: > > > In message <20000621145255.I214@dialin-client.earthlink.net>, "Crist J. Clark" writes: > > > > > > > > Having a rule like, > > > > > > > > ipfw add 2350 pass tcp from any 20 to x.x.x.x port_high1-port_high2 > > > > > > > > Is not really too much of a risk (I don't remember what the range of > > > > valid ports is). Make sure you don't have anything you are not > > > > comfortable with listening in that range. The rule to allow the > > > > initial ftp connection is much, much more risky than the above. > > > > > > I vehemently disagree. It is a high risk because an attacker can > > > connect to services running on ports >= 1024, e.g. Oracle. Even if > > > you're not running any services >= 1024, it is trivial to scan your > > > network to get a picture of what it looks like to plan a strategy of > > > attack. IMO too much risk. > > > > How can can an attacker scan the network when the high ports are only > > open for this one host? > > An attacker won't be able to scan the low ports but will be able to > determine which IP addresses (hosts) are on the inside. If an attacker > scans ports >= 1024 he'll easily discover services running on those > ports. > > Think about it: > > ipfw add allow tcp from any 20 to any 1024-65535 in > > allows port 20 to initiate connects to any non-privileged port on > your network like X and some Kerberos services. I agree that _that_ is a dangerous rule, but we were discussing, ipfw add allow tcp from any 20 to x.x.x.x 1024-65535 To the one ftp server, 'x.x.x.x,' and NOT 'any.' You can only directly scan that one host. > > > > Actually, this would be a good place for keep-state to work. I'm kinda > > > > surprised that no one has added a keep-state method for FTP. It'd just > > > > be, > > > > > > > > ipfw add 2350 pass tcp from any to x.x.x.x 21 setup keep-state ftp > > > > > > > > Right? Creating a dynamic rule that passes traffic from 20 to > > > > x.x.x.x. From how I understand keep-state to work (and it is minimal, > > > > sorry), it should not be too difficult to do? > > > > > > Agreed, under IPFW this cannot be done. > > > > As ipfw(8) is currently implemented? Or is this something that cannot > > (or should not) be done with ipfw? > > IPFW does not support an FTP application proxy, period. Take a look > for yourself. I know it does not proxy and would not ever want ipfw to actually modify packets. I just wonder about a dynamic rule that opens the high ports of a machine to source port 20 when a keep-state is triggered for a incoming setup to port 21 of that machine. I know it does not do this now, keep-state [method] Upon a match, the firewall will create a dynamic rule, whose default behaviour is to matching bidirectional traffic between source and destination IP/port using the same protocol... [snip] The actual behaviour can be modified by specifying a dif- ferent method, although at the moment only the default one is specified. Notice "at the moment." I am saying is there a reason one could not or should not code in another 'method' to do PORT ftp. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Jun 23 20:43:47 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id AD84937B528 for ; Fri, 23 Jun 2000 20:43:35 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id UAA25973; Fri, 23 Jun 2000 20:43:00 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda25969; Fri Jun 23 20:42:49 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id UAA05540; Fri, 23 Jun 2000 20:42:48 -0700 (PDT) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdTc5538; Fri Jun 23 20:42:34 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.10.2/8.9.1) id e5O3gXr14008; Fri, 23 Jun 2000 20:42:33 -0700 (PDT) Message-Id: <200006240342.e5O3gXr14008@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdC14004; Fri Jun 23 20:41:45 2000 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.0-STABLE X-Sender: cy To: cjclark@alum.mit.edu Cc: Cy Schubert - ITSD Open Systems Group , Jennifer Ulrich , freebsd-ipfw@FreeBSD.ORG Subject: Re: allowing passive ftp through ipfw In-reply-to: Your message of "Fri, 23 Jun 2000 19:25:46 PDT." <20000623192546.A481@dialin-client.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Jun 2000 20:41:45 -0700 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000623192546.A481@dialin-client.earthlink.net>, "Crist J. Clark" writes: [getting too long, trimmed] > > > As ipfw(8) is currently implemented? Or is this something that cannot > > > (or should not) be done with ipfw? > > > > IPFW does not support an FTP application proxy, period. Take a look > > for yourself. > > I know it does not proxy and would not ever want ipfw to actually > modify packets. I just wonder about a dynamic rule that opens the high > ports of a machine to source port 20 when a keep-state is triggered > for a incoming setup to port 21 of that machine. I know it does not do > this now, > > keep-state [method] > Upon a match, the firewall will create a dynamic rule, > whose default behaviour is to matching bidirectional > traffic between source and destination IP/port using the > same protocol... > [snip] > The actual behaviour can be modified by specifying a dif > - > ferent method, although at the moment only the default > one is specified. > > Notice "at the moment." I am saying is there a reason one could not or > should not code in another 'method' to do PORT ftp. One could code another method to do PORT FTP. I think that this method should be put into natd, as NAT and application proxies, like an FTP proxy is especially useful when used with NAT. A PORT FTP proxy would only satisfy the requirements of performing PORT FTP for a client behind a firewall. A passive FTP proxy would also need to be built for an FTP server behind a firewall -- similar issues of an FTP server with passive FTP behind a firewall as an FTP client using PORT FTP behind a firewall. This is what IP Filter does in proxying FTP for FTP servers and clients, solving similar problems but in reverse. Also when writing an FTP proxy one must keep in mind the exploit of statefull firewalls FTP proxies by tricking an FTP server or client (depending on the context) into producing a message that would be interpreted by the proxy to open up arbitrary holes in the firewall which would be used to access arbitrary ports on the FTP server or client (once again depending on the context). See the BUGTRAQ archives from March or April for more details. I think the discussions were entitled FW-1 vulnerability and FTP ALG vulnerability. The vulnerabilities discussed affected many (all?) known statefull firewalls at the time. For an example what is needed to plug the FTP ALG vulnerability, e.g. to keep in mind when writing an FTP proxy, take a look at the diffs between IP Filter 3.3.11 and 3.3.12, and subsequently 3.4.x where stricter criteria are used to make sure that an FTP session is kosher before allowing FTP proxy. It's all pretty cool stuff, especially considering all the work that goes into building software like this. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message