From owner-freebsd-ipfw Mon May 14 10:25:43 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from apocalypse.cdsnet.net (apocalypse.cdsnet.net [63.163.68.5]) by hub.freebsd.org (Postfix) with SMTP id 1D9D837B43C for ; Mon, 14 May 2001 10:25:37 -0700 (PDT) (envelope-from mrcpu@apocalypse.cdsnet.net) Received: (qmail 19906 invoked by uid 29999); 14 May 2001 17:25:24 -0000 Date: Mon, 14 May 2001 10:25:24 -0700 From: Jaye Mathisen To: ipfw@freebsd.org Subject: WHat controls the lifetime of UDP rules? Message-ID: <20010514102524.R85928@apocalypse.cdsnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If you use a keep-state on a UDP rule, what sysctl variable controls the expiration of that rule? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon May 14 16:42:39 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 79A9637B42C for ; Mon, 14 May 2001 16:42:38 -0700 (PDT) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id 2A38781D06; Mon, 14 May 2001 18:42:28 -0500 (CDT) Date: Mon, 14 May 2001 18:42:28 -0500 From: Bill Fumerola To: Jaye Mathisen Cc: ipfw@freebsd.org Subject: Re: WHat controls the lifetime of UDP rules? Message-ID: <20010514184228.J37979@elvis.mu.org> References: <20010514102524.R85928@apocalypse.cdsnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010514102524.R85928@apocalypse.cdsnet.net>; from mrcpu@internetcds.com on Mon, May 14, 2001 at 10:25:24AM -0700 X-Operating-System: FreeBSD 4.3-FEARSOME-20010328 i386 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, May 14, 2001 at 10:25:24AM -0700, Jaye Mathisen wrote: > > If you use a keep-state on a UDP rule, what sysctl variable controls the expiration of that rule? dyn_short_lifetime -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue May 15 4:10:13 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 15BBC37B424; Tue, 15 May 2001 04:09:47 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f4FB9iK42189; Tue, 15 May 2001 14:09:44 +0300 (EEST) (envelope-from ru) Date: Tue, 15 May 2001 14:09:43 +0300 From: Ruslan Ermilov To: Bill Fumerola , Luigi Rizzo Cc: ipfw@FreeBSD.org Subject: Re: ipfw rules and securelevel Message-ID: <20010515140943.A41014@sunbay.com> Mail-Followup-To: Bill Fumerola , Luigi Rizzo , ipfw@FreeBSD.org References: <10320318256.20010514212856@morning.ru> <19322552168.20010514220610@morning.ru> <20010514170927.A849@ringworld.oblivion.bg> <5523460344.20010514222118@morning.ru> <20010514180201.C453@ringworld.oblivion.bg> <20010514180928.A52742@sunbay.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010514180928.A52742@sunbay.com>; from ru@FreeBSD.org on Mon, May 14, 2001 at 06:09:28PM +0300 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [Redirected to -ipfw] On Mon, May 14, 2001 at 06:09:28PM +0300, Ruslan Ermilov wrote: > On Mon, May 14, 2001 at 06:02:02PM +0300, Peter Pentchev wrote: > > On Mon, May 14, 2001 at 10:21:18PM +0700, Igor Podlesny wrote: > > > > > > > > > > On Mon, May 14, 2001 at 10:06:10PM +0700, Igor Podlesny wrote: > > > >> > > > >> >> Dear friends, > > > >> >> Even in securelevel 3 I can bypass ipfw rules. In securelevel 3 I > > > >> >> as root can change the variable "net.inet.ip.fw.enable" using sysctl. When > > > >> >> I run a command > > > >> > > > >> >> sysctl -w net.inet.ip.fw.enable=0 > > > >> > > > >> >> It disables the ipfw rules. > > > >> > > > >> >> Is it a feature or hole in freebsd. > > > >> > > > >> > doesn't matter how it is called, only matters how it hurts... (it does) > > > >> > > > >> >> please help > > > >> > > > >> the "patch" (hard to call it a patch, but nevertheless) is adding > > > >> CTLFLAG_SECURE to the relevant definition of the node: > > > >> > > > >> this diff out is for 3.5 stable: > > > >> > > > >> 92c92 > > > >> < SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW, > > > >> --- > > > >> > SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW|CTLFLAG_SECURE, > > > > > > > Patches/diffs are usually much easier to review and apply if they are > > > > in context or unified diff format - this helps when the patch is made > > > > against a possibly changed file :) And.. well.. it might be obvious > > > > to you (in this case it's pretty obvious to figure out ;), but still > > > > it helps a lot to mention which file(s) the patch is against :) > > > > > > oh, you're right :) > > > > > > it was > > > /usr/src/sys/netinet/ip_fw.c > > > > > > unified diff: > > > > > > --- /usr/src/sys/netinet/ip_fw.c.orig Fri Mar 23 19:44:27 2001 > > > +++ /usr/src/sys/netinet/ip_fw.c Mon May 14 22:15:55 2001 > > > @@ -89,7 +89,7 @@ > > > > > > #ifdef SYSCTL_NODE > > > SYSCTL_NODE(_net_inet_ip, OID_AUTO, fw, CTLFLAG_RW, 0, "Firewall"); > > > -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW, > > > +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW|CTLFLAG_SECURE, > > > &fw_enable, 0, "Enable ipfw"); > > > SYSCTL_INT(_net_inet_ip_fw, OID_AUTO,one_pass,CTLFLAG_RW, > > > &fw_one_pass, 0, > > > > Yup, this patch is much clearer, and I see no real reason against > > committing it. Actually, I think that even more of those sysctl's > > should be flagged as 'secure' - e.g. the ones related to logging. > > > Hmm, but I think that for (securelevel < 3) the transition should > still be allowed. The correct fix then would be: > > Index: ip_fw.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v > retrieving revision 1.164 > diff -u -p -r1.164 ip_fw.c > --- ip_fw.c 2001/04/06 06:52:25 1.164 > +++ ip_fw.c 2001/05/14 15:04:12 > @@ -96,9 +96,19 @@ LIST_HEAD (ip_fw_head, ip_fw_chain) ip_f > MALLOC_DEFINE(M_IPFW, "IpFw/IpAcct", "IpFw/IpAcct chain's"); > > #ifdef SYSCTL_NODE > + > +static int > +sysctl_fw_enable(SYSCTL_HANDLER_ARGS) > +{ > + > + if (req->newptr && securelevel >= 3) > + return (EPERM); > + return sysctl_handle_int(oidp, arg1, arg2, req); > +} > + > SYSCTL_NODE(_net_inet_ip, OID_AUTO, fw, CTLFLAG_RW, 0, "Firewall"); > -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW, > - &fw_enable, 0, "Enable ipfw"); > +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, enable, CTLTYPE_INT|CTLFLAG_RW, > + &fw_enable, 0, sysctl_fw_enable, "I", "Enable ipfw"); > SYSCTL_INT(_net_inet_ip_fw, OID_AUTO,one_pass,CTLFLAG_RW, > &fw_one_pass, 0, > "Only do a single pass through ipfw when using dummynet(4)"); > Here is a slightly reworked version of the above patch. It prohibits all MIB modifications under net.inet.ip.fw node except a few ones: debug, verbose, and verbose_limit that shouldn't affect security. Please review. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: ip_fw.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v retrieving revision 1.164 diff -u -p -r1.164 ip_fw.c --- ip_fw.c 2001/04/06 06:52:25 1.164 +++ ip_fw.c 2001/05/15 10:57:41 @@ -96,11 +96,21 @@ LIST_HEAD (ip_fw_head, ip_fw_chain) ip_f MALLOC_DEFINE(M_IPFW, "IpFw/IpAcct", "IpFw/IpAcct chain's"); #ifdef SYSCTL_NODE + +static int +sysctl_fw_securelevel_check(SYSCTL_HANDLER_ARGS) +{ + + if (req->newptr && securelevel >= 3) + return (EPERM); + return sysctl_handle_int(oidp, arg1, arg2, req); +} + SYSCTL_NODE(_net_inet_ip, OID_AUTO, fw, CTLFLAG_RW, 0, "Firewall"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW, - &fw_enable, 0, "Enable ipfw"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO,one_pass,CTLFLAG_RW, - &fw_one_pass, 0, +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, enable, CTLTYPE_INT|CTLFLAG_RW, + &fw_enable, 0, sysctl_fw_securelevel_check, "I", "Enable ipfw"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, one_pass, CTLTYPE_INT|CTLFLAG_RW, + &fw_one_pass, 0, sysctl_fw_securelevel_check, "I", "Only do a single pass through ipfw when using dummynet(4)"); SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, debug, CTLFLAG_RW, &fw_debug, 0, "Enable printing of debug ip_fw statements"); @@ -108,8 +118,9 @@ SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, ve &fw_verbose, 0, "Log matches to ipfw rules"); SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, verbose_limit, CTLFLAG_RW, &fw_verbose_limit, 0, "Set upper limit of matches of ipfw rules logged"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, permanent_rules, CTLFLAG_RW, - &fw_permanent_rules, 0, "Set rule number, below which rules are permanent"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, permanent_rules, CTLTYPE_INT|CTLFLAG_RW, + &fw_permanent_rules, 0, sysctl_fw_securelevel_check, "I", + "Set rule number, below which rules are permanent"); /* * Extension for stateful ipfw. @@ -163,24 +174,31 @@ static u_int32_t dyn_rst_lifetime = 5 ; static u_int32_t dyn_short_lifetime = 30 ; static u_int32_t dyn_count = 0 ; static u_int32_t dyn_max = 1000 ; -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_buckets, CTLFLAG_RW, - &dyn_buckets, 0, "Number of dyn. buckets"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, curr_dyn_buckets, CTLFLAG_RD, - &curr_dyn_buckets, 0, "Current Number of dyn. buckets"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_count, CTLFLAG_RD, - &dyn_count, 0, "Number of dyn. rules"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_max, CTLFLAG_RW, - &dyn_max, 0, "Max number of dyn. rules"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_ack_lifetime, CTLFLAG_RW, - &dyn_ack_lifetime, 0, "Lifetime of dyn. rules for acks"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_syn_lifetime, CTLFLAG_RW, - &dyn_syn_lifetime, 0, "Lifetime of dyn. rules for syn"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_fin_lifetime, CTLFLAG_RW, - &dyn_fin_lifetime, 0, "Lifetime of dyn. rules for fin"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_rst_lifetime, CTLFLAG_RW, - &dyn_rst_lifetime, 0, "Lifetime of dyn. rules for rst"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_short_lifetime, CTLFLAG_RW, - &dyn_short_lifetime, 0, "Lifetime of dyn. rules for other situations"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, dyn_buckets, CTLTYPE_INT|CTLFLAG_RW, + &dyn_buckets, 0, sysctl_fw_securelevel_check, "IU", + "Number of dyn. buckets"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, curr_dyn_buckets, CTLTYPE_INT|CTLFLAG_RD, + &curr_dyn_buckets, 0, sysctl_fw_securelevel_check, "IU", + "Current Number of dyn. buckets"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, dyn_count, CTLTYPE_INT|CTLFLAG_RD, + &dyn_count, 0, sysctl_fw_securelevel_check, "IU", "Number of dyn. rules"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, dyn_max, CTLTYPE_INT|CTLFLAG_RW, + &dyn_max, 0, sysctl_fw_securelevel_check, "IU", "Max number of dyn. rules"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, dyn_ack_lifetime, CTLTYPE_INT|CTLFLAG_RW, + &dyn_ack_lifetime, 0, sysctl_fw_securelevel_check, "IU", + "Lifetime of dyn. rules for acks"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, dyn_syn_lifetime, CTLTYPE_INT|CTLFLAG_RW, + &dyn_syn_lifetime, 0, sysctl_fw_securelevel_check, "IU", + "Lifetime of dyn. rules for syn"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, dyn_fin_lifetime, CTLTYPE_INT|CTLFLAG_RW, + &dyn_fin_lifetime, 0, sysctl_fw_securelevel_check, "IU", + "Lifetime of dyn. rules for fin"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, dyn_rst_lifetime, CTLTYPE_INT|CTLFLAG_RW, + &dyn_rst_lifetime, 0, sysctl_fw_securelevel_check, "IU", + "Lifetime of dyn. rules for rst"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, dyn_short_lifetime, + CTLTYPE_INT|CTLFLAG_RW, &dyn_short_lifetime, 0, sysctl_fw_securelevel_check, + "IU", "Lifetime of dyn. rules for other situations"); #endif --tThc/1wpZn/ma/RB-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue May 15 4:22: 1 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 5604A37B43C for ; Tue, 15 May 2001 04:21:58 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 15751 invoked by uid 1000); 15 May 2001 11:21:18 -0000 Date: Tue, 15 May 2001 14:21:18 +0300 From: Peter Pentchev To: Ruslan Ermilov Cc: Bill Fumerola , Luigi Rizzo , ipfw@FreeBSD.org Subject: Re: ipfw rules and securelevel Message-ID: <20010515142118.G11592@ringworld.oblivion.bg> References: <10320318256.20010514212856@morning.ru> <19322552168.20010514220610@morning.ru> <20010514170927.A849@ringworld.oblivion.bg> <5523460344.20010514222118@morning.ru> <20010514180201.C453@ringworld.oblivion.bg> <20010514180928.A52742@sunbay.com> <20010515140943.A41014@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010515140943.A41014@sunbay.com>; from ru@FreeBSD.org on Tue, May 15, 2001 at 02:09:43PM +0300 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, May 15, 2001 at 02:09:43PM +0300, Ruslan Ermilov wrote: > Here is a slightly reworked version of the above patch. It prohibits > all MIB modifications under net.inet.ip.fw node except a few ones: > debug, verbose, and verbose_limit that shouldn't affect security. > Please review. I wonder if verbose and verbose_limit shouldn't also be prohibited. Arguably, if someone has obtained superuser privileges on your securelevel 3 box, they don't need to try any more exploits or something. Still, I personally would maybe feel a bit more warm and fuzzy if I knew that no one could disable ipfw logging, even if the system is already compromised. G'luck, Peter -- What would this sentence be like if pi were 3? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue May 15 16:43:42 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id DC83F37B42C; Tue, 15 May 2001 16:43:39 -0700 (PDT) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id 8C99D81D06; Tue, 15 May 2001 18:43:29 -0500 (CDT) Date: Tue, 15 May 2001 18:43:29 -0500 From: Bill Fumerola To: Peter Pentchev Cc: Ruslan Ermilov , Luigi Rizzo , ipfw@FreeBSD.org Subject: Re: ipfw rules and securelevel Message-ID: <20010515184329.O37979@elvis.mu.org> References: <10320318256.20010514212856@morning.ru> <19322552168.20010514220610@morning.ru> <20010514170927.A849@ringworld.oblivion.bg> <5523460344.20010514222118@morning.ru> <20010514180201.C453@ringworld.oblivion.bg> <20010514180928.A52742@sunbay.com> <20010515140943.A41014@sunbay.com> <20010515142118.G11592@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010515142118.G11592@ringworld.oblivion.bg>; from roam@orbitel.bg on Tue, May 15, 2001 at 02:21:18PM +0300 X-Operating-System: FreeBSD 4.3-FEARSOME-20010328 i386 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, May 15, 2001 at 02:21:18PM +0300, Peter Pentchev wrote: > > Here is a slightly reworked version of the above patch. It prohibits > > all MIB modifications under net.inet.ip.fw node except a few ones: > > debug, verbose, and verbose_limit that shouldn't affect security. > > Please review. > > I wonder if verbose and verbose_limit shouldn't also be prohibited. > Arguably, if someone has obtained superuser privileges on your securelevel > 3 box, they don't need to try any more exploits or something. > Still, I personally would maybe feel a bit more warm and fuzzy if I knew > that no one could disable ipfw logging, even if the system is already > compromised. When Ruslan asked me earlier regarding verbose, I told him not to prohibit it. Why? In time of attack or crisis, kicking up the debugging on your firewall is important. The only local problems I could see this causing is someone kicking up the limit to a really high number and flooding. We already allow people to resetlog at that securelevel so the associated sysctls should stick with that security model. thanks, -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue May 15 19:37:50 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from VL-MS-MR003.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id 2A40F37B43C for ; Tue, 15 May 2001 19:37:46 -0700 (PDT) (envelope-from davitron@vl.videotron.ca) Received: from kerijan.davitron.org ([24.202.255.5]) by VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id GDEPYW04.ZX0 for ; Tue, 15 May 2001 22:37:44 -0400 Content-Type: text/plain; charset="iso-8859-5" From: David Comeau Reply-To: davitron@vl.videotron.ca Organization: DaviTronique To: ipfw@FreeBSD.org Subject: Help with passing a variable. Date: Tue, 15 May 2001 22:37:49 -0400 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01051522374901.01545@kerijan.davitron.org> Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG To all listeners, I am using the videotron.ca cable-modem service here in Montreal, Qc. In the /etc/rc.firewall file there are areas where we must reflect our sy= stem=20 setup (Ip, ...) Since I am on a cable-modem using DHCP, I would like to k= now=20 if it is possible to reflect that fact in the "oif" variable? If so, how=20 exactly? I have included part of my rc.conf as wel as the part of rc.firewall that= I'm=20 talking about. i hope it is enough for some sort of answer. * From /etc/rc.conf ***************** gateway_enable=3D"YES" network_interfaces=3D"ed0 ed1 lo0" firewall_enable=3D"YES" firewall_script=3D"/etc/rc.firewall" firewall_type=3D"open" firewall_quiet=3D"YES" #change to YES once happy with rules firewall_logging=3D"YES" tcp_extensions=3D"NO" log_in_vain=3D"YES" tcp_keepalive=3D"YES" tcp_drop_synfin=3D"NO" #change to NO if create webserver tcp_restrict_rst=3D"NO" icmp_drop_redirect=3D"NO" icmp_log_redirect=3D"NO" natd_enable=3D"YES" natd_program=3D"/sbin/natd" natd_flags=3D"-f /etc/natd.cf" natd_interface=3D"ed0" * From /etc/rc.firewall simple firewall section ************************= *** # set these to your outside interface network and netmask and ip oif=3D"ed0" onet=3D"" # How do I add a variable to reflect the fact that it = is=20 DHCP? omask=3D"255.255.255.0" oip=3D"" # Can I add a variable to reflect the fact that it is = DHCP? # set these to your inside interface network and netmask and ip iif=3D"ed1" inet=3D"192.168.1.0" imask=3D"255.255.255.0" iip=3D"192.168.1.1" --=20 Sincerely, David Comeau http://www.davitron.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue May 15 19:42: 0 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from web11604.mail.yahoo.com (web11604.mail.yahoo.com [216.136.172.56]) by hub.freebsd.org (Postfix) with SMTP id 8421637B423 for ; Tue, 15 May 2001 19:41:56 -0700 (PDT) (envelope-from holtor@yahoo.com) Message-ID: <20010516024156.89744.qmail@web11604.mail.yahoo.com> Received: from [216.65.99.194] by web11604.mail.yahoo.com; Tue, 15 May 2001 19:41:56 PDT Date: Tue, 15 May 2001 19:41:56 -0700 (PDT) From: Holtor Subject: Bandwidth Limiting per IP To: ipfw@FreeBSD.ORG Cc: questions@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi All, I have a machine with several IP aliases to a single interface. I want to limit each IP to say 100 kbits in/out. Do I need to create seperate pipes for each IP and then create the normal ipfw rules? Or will one pipe of a limit of 100 kbit and linking the other IPFW rules to it be enough? My concern is that when the limit for one IP is reached I do not want to to affect the other IPs. I think (am pretty sure) i need seperate pipes and rules.. Then if so is there any ill effect for creating many pipes? One of my machines has over 100 IPs here. Thanks in advance for any help offered. Please reply to me directly aswell since i'm not on the list(s). Thank You, Holt __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue May 15 23:31:39 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from mip.co.za (puck.mip.co.za [209.212.106.44]) by hub.freebsd.org (Postfix) with ESMTP id 7764537B423; Tue, 15 May 2001 23:31:24 -0700 (PDT) (envelope-from patrick@mip.co.za) Received: from patrick (patrick.mip.co.za [10.3.13.181]) by mip.co.za (8.9.3/8.9.3) with SMTP id IAA87213; Wed, 16 May 2001 08:31:17 +0200 (SAST) (envelope-from patrick@mip.co.za) From: "Patrick O'Reilly" To: , "Holtor" Cc: Subject: RE: Bandwidth Limiting per IP Date: Wed, 16 May 2001 08:29:46 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <20010516024156.89744.qmail@web11604.mail.yahoo.com> Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Holt, Your conclusion is correct - you do need a pipe for each IP with 100kbit per pipe. If you only have 1 pipe then all the IPS will SHARE the 100 kbit, which is not what you want. There is additional overhead in processing so many pipes, but if the box in question is doing nothing other than acting as a gateway/router then I doubt that this will be a real problem. I have a vague memory that someone once benchmarked a set if ipfw rules and found that with a set of 1000 rules (the average search would therefore hit at about rule 500) the actual latency induced was just a few milliseconds. Patrick. -----Original Message----- From: owner-freebsd-ipfw@FreeBSD.ORG [mailto:owner-freebsd-ipfw@FreeBSD.ORG]On Behalf Of Holtor Sent: 16 May 2001 04:42 To: ipfw@FreeBSD.ORG Cc: questions@FreeBSD.ORG Subject: Bandwidth Limiting per IP Hi All, I have a machine with several IP aliases to a single interface. I want to limit each IP to say 100 kbits in/out. Do I need to create seperate pipes for each IP and then create the normal ipfw rules? Or will one pipe of a limit of 100 kbit and linking the other IPFW rules to it be enough? My concern is that when the limit for one IP is reached I do not want to to affect the other IPs. I think (am pretty sure) i need seperate pipes and rules.. Then if so is there any ill effect for creating many pipes? One of my machines has over 100 IPs here. Thanks in advance for any help offered. Please reply to me directly aswell since i'm not on the list(s). Thank You, Holt __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue May 15 23:37:47 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 07DCA37B42C; Tue, 15 May 2001 23:37:44 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.11.3/8.11.3) id f4G6bGo04788; Wed, 16 May 2001 01:37:16 -0500 (CDT) (envelope-from dan) Date: Wed, 16 May 2001 01:37:16 -0500 From: Dan Nelson To: "Patrick O'Reilly" Cc: ipfw@FreeBSD.ORG, Holtor , questions@FreeBSD.ORG Subject: Re: Bandwidth Limiting per IP Message-ID: <20010516013716.B26749@dan.emsphone.com> References: <20010516024156.89744.qmail@web11604.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from "Patrick O'Reilly" on Wed May 16 08:29:46 GMT 2001 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (May 16), Patrick O'Reilly said: > Your conclusion is correct - you do need a pipe for each IP with > 100kbit per pipe. If you only have 1 pipe then all the IPS will > SHARE the 100 kbit, which is not what you want. Actually, you can get away with one pipe, but use the pipe mask keyword to tell the pipe code to count each internal IP separately. See the bottom of the the ipfw manpage; there is an example that does almost exactly what you're asking, I think. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue May 15 23:39:39 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id BE9DC37B424; Tue, 15 May 2001 23:39:27 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id IAA44066; Wed, 16 May 2001 08:36:24 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200105160636.IAA44066@info.iet.unipi.it> Subject: Re: Bandwidth Limiting per IP In-Reply-To: from "Patrick O'Reilly" at "May 16, 2001 08:29:46 am" To: "Patrick O'Reilly" Date: Wed, 16 May 2001 08:36:24 +0200 (CEST) Cc: ipfw@FreeBSD.ORG, Holtor , questions@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > There is additional overhead in processing so many pipes, but if the box in actually, if you use dynamic pipes e.g. ipfw add pipe 1 ip from 10.1.2.0/24 to any ipfw pipe 1 config bw 100Kbit/s mask src-ip 0x000000ff then everything works pretty fast -- the ruleset is short, and the pipe processing overhead is O(log n) where n is the number of _active_ pipes. In cases like these i would also suggest the use of fair queueing, which works well in 4.3 ipfw add queue 1 ip from 10.1.2.0/24 to any ipfw pipe 10 config bw 2Mbit/s ipfw queue 1 config pipe 1 weight 30 mask src-ip 0x000000ff so all active flows get an equal share of the total capacity. > question is doing nothing other than acting as a gateway/router then I doubt > that this will be a real problem. I have a vague memory that someone once > benchmarked a set if ipfw rules and found that with a set of 1000 rules (the > average search would therefore hit at about rule 500) the actual latency > induced was just a few milliseconds. yep -- but the 'mask' mechanism often saves you from using so many rules. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed May 16 1: 4:31 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from mip.co.za (puck.mip.co.za [209.212.106.44]) by hub.freebsd.org (Postfix) with ESMTP id 7612E37B422 for ; Wed, 16 May 2001 01:04:23 -0700 (PDT) (envelope-from patrick@mip.co.za) Received: from patrick (patrick.mip.co.za [10.3.13.181]) by mip.co.za (8.9.3/8.9.3) with SMTP id KAA89139; Wed, 16 May 2001 10:04:16 +0200 (SAST) (envelope-from patrick@mip.co.za) From: "Patrick O'Reilly" To: , "Holtor" Subject: RE: Bandwidth Limiting per IP Date: Wed, 16 May 2001 10:00:43 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Holt, You have obviously seen the other replies from Luigi and Dan - both of whom are far more expert than myself on ipfw and dummynet - so read their info carefully, and have fun. Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed May 16 1:46:22 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 48ECF37B422 for ; Wed, 16 May 2001 01:46:19 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 24051 invoked by uid 1000); 16 May 2001 08:45:38 -0000 Date: Wed, 16 May 2001 11:45:38 +0300 From: Peter Pentchev To: Bill Fumerola Cc: Ruslan Ermilov , Luigi Rizzo , ipfw@FreeBSD.org Subject: Re: ipfw rules and securelevel Message-ID: <20010516114538.A23970@ringworld.oblivion.bg> References: <10320318256.20010514212856@morning.ru> <19322552168.20010514220610@morning.ru> <20010514170927.A849@ringworld.oblivion.bg> <5523460344.20010514222118@morning.ru> <20010514180201.C453@ringworld.oblivion.bg> <20010514180928.A52742@sunbay.com> <20010515140943.A41014@sunbay.com> <20010515142118.G11592@ringworld.oblivion.bg> <20010515184329.O37979@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010515184329.O37979@elvis.mu.org>; from billf@mu.org on Tue, May 15, 2001 at 06:43:29PM -0500 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, May 15, 2001 at 06:43:29PM -0500, Bill Fumerola wrote: > On Tue, May 15, 2001 at 02:21:18PM +0300, Peter Pentchev wrote: > > > > Here is a slightly reworked version of the above patch. It prohibits > > > all MIB modifications under net.inet.ip.fw node except a few ones: > > > debug, verbose, and verbose_limit that shouldn't affect security. > > > Please review. > > > > I wonder if verbose and verbose_limit shouldn't also be prohibited. > > Arguably, if someone has obtained superuser privileges on your securelevel > > 3 box, they don't need to try any more exploits or something. > > Still, I personally would maybe feel a bit more warm and fuzzy if I knew > > that no one could disable ipfw logging, even if the system is already > > compromised. > > When Ruslan asked me earlier regarding verbose, I told him not to prohibit it. > > Why? In time of attack or crisis, kicking up the debugging on your firewall > is important. The only local problems I could see this causing is someone > kicking up the limit to a really high number and flooding. > > We already allow people to resetlog at that securelevel so the associated > sysctls should stick with that security model. Ah. All good points. OK, I agree that the rest need not be protected. G'luck, Peter -- I am the thought you are now thinking. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed May 16 8:23:30 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by hub.freebsd.org (Postfix) with ESMTP id DED3837B422; Wed, 16 May 2001 08:23:26 -0700 (PDT) (envelope-from rjmcintire@earthlink.net) Received: from emilyd ([64.161.77.242]) by mta7.pltn13.pbi.net (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10) with SMTP id <0GDF000NGPEKX5@mta7.pltn13.pbi.net>; Wed, 16 May 2001 08:23:09 -0700 (PDT) Date: Wed, 16 May 2001 08:23:08 -0700 From: "Riley J. McIntire" Subject: RE: Bandwidth Limiting per IP In-reply-to: <200105160636.IAA44066@info.iet.unipi.it> To: Luigi Rizzo , Patrick O'Reilly Cc: ipfw@FreeBSD.ORG, Holtor , questions@FreeBSD.ORG Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Priority: 3 (Normal) Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Luigi, It looks like you have a typo here. > then everything works pretty fast -- the ruleset is short, and > the pipe processing overhead is O(log n) where n is the number of > _active_ pipes. 0(log n) = 0 is pretty low overhead. n(log n) would seem more appropriate if I had to guess. Riley To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed May 16 8:51:20 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id A12FD37B422; Wed, 16 May 2001 08:51:15 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id RAA48567; Wed, 16 May 2001 17:48:12 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200105161548.RAA48567@info.iet.unipi.it> Subject: Re: Bandwidth Limiting per IP In-Reply-To: from "Riley J. McIntire" at "May 16, 2001 08:23:08 am" To: "Riley J. McIntire" Date: Wed, 16 May 2001 17:48:12 +0200 (CEST) Cc: "Patrick O'Reilly" , ipfw@FreeBSD.ORG, Holtor , questions@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Luigi, > > It looks like you have a typo here. it looks you have forgotten the smiley :) in your msg. If not, then you have a bad font, because O != 0 cheers luigi > > then everything works pretty fast -- the ruleset is short, and > > the pipe processing overhead is O(log n) where n is the number of > > _active_ pipes. > > 0(log n) = 0 is pretty low overhead. > > n(log n) would seem more appropriate if I had to guess. > > Riley > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message