From owner-freebsd-ipfw Mon Jul 26 11:18:22 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 0EB1B14FB3; Mon, 26 Jul 1999 11:18:10 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id NAA05470; Mon, 26 Jul 1999 13:16:57 -0500 (CDT) From: Joe Greco Message-Id: <199907261816.NAA05470@aurora.sol.net> Subject: securelevel and ipfw zero To: freebsd-hackers@freebsd.org Date: Mon, 26 Jul 1999 13:16:57 -0500 (CDT) Cc: freebsd-ipfw@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (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 Hello, So, I've a box that I have an ipfw ruleset on. The firewall should not be changeable during runtime, and the box runs at securelevel=3. In order to prevent DoS disk-fill attacks, I also have specified IPFW_VERBOSE_LIMIT. Now, the problem is, in securelevel 3, you cannot zero a rule's counter, so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT events and then you lose logging (ideally I'd zero nonzero rules once every N minutes). Comments? ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 26 11:48:52 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 5B3C714D3E; Mon, 26 Jul 1999 11:48:48 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA48202; Mon, 26 Jul 1999 11:47:20 -0700 (PDT) (envelope-from dillon) Date: Mon, 26 Jul 1999 11:47:20 -0700 (PDT) From: Matthew Dillon Message-Id: <199907261847.LAA48202@apollo.backplane.com> To: Joe Greco Cc: freebsd-hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero References: <199907261816.NAA05470@aurora.sol.net> Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Hello, : :So, I've a box that I have an ipfw ruleset on. The firewall should not be :changeable during runtime, and the box runs at securelevel=3. : :In order to prevent DoS disk-fill attacks, I also have specified :IPFW_VERBOSE_LIMIT. : :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT :events and then you lose logging (ideally I'd zero nonzero rules once every :N minutes). : :Comments? : :... Joe : :------------------------------------------------------------------------------- :Joe Greco - Systems Administrator jgreco@ns.sol.net Playing devil's advocate, someone might be using those counters for accounting purposes. That's about as worse a scenario as I can think of, and I can't imagine this sort of situation would be prevalient. I'd say that the counters should be clearable at high secure level. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 26 12: 8:44 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id C000414CC2; Mon, 26 Jul 1999 12:08:40 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id OAA08989; Mon, 26 Jul 1999 14:07:11 -0500 (CDT) From: Joe Greco Message-Id: <199907261907.OAA08989@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907261847.LAA48202@apollo.backplane.com> from Matthew Dillon at "Jul 26, 1999 11:47:20 am" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Mon, 26 Jul 1999 14:07:10 -0500 (CDT) Cc: hackers@freebsd.org, freebsd-ipfw@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (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 > :Hello, > : > :So, I've a box that I have an ipfw ruleset on. The firewall should not be > :changeable during runtime, and the box runs at securelevel=3. > : > :In order to prevent DoS disk-fill attacks, I also have specified > :IPFW_VERBOSE_LIMIT. > : > :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, > :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT > :events and then you lose logging (ideally I'd zero nonzero rules once every > :N minutes). > : > :Comments? > > Playing devil's advocate, someone might be using those counters for > accounting purposes. That's about as worse a scenario as I can think > of, and I can't imagine this sort of situation would be prevalient. > > I'd say that the counters should be clearable at high secure level. Then there should be a separate counter for logging purposes...? I do not care if the accounting counters do not clear (ever), since things like MRTG are designed to deal with that situation. However, it seems bad that you would not be able to clear your counter for logging purposes, just in case you actually _did_ mean that you want bad packets to be logged. I will also note that it would be acceptable, to me at least, to maintain a global (rather than per-rule) limit for the verbose limit. In general, I would think that someone who uses the limit facility is trying to avoid a DoS style disk-space attack. Having a per-rule limit means that you actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit (assuming an attacker exploits multiple rules) rather than a limit of "IPFW_VERBOSE_LIMIT". It also makes it more difficult to code in a bunch of "log" rules, since your periodic "zero" script has to know the number of each one, and if you just do an "ipfw zero rule1 rule2 rule3...." then you get a bunch of /kernel: ipfw: Entry rule1 cleared. /kernel: ipfw: Entry rule2 cleared. /kernel: ipfw: Entry rule3 cleared. each time you do this. I would rather see something like /kernel: ipfw: logging limit reached, suspending. # /sbin/ipfw zerolog /kernel: ipfw: logging limit reset, resuming. I can deal with it (in code) if there is a per-rule log counter as well, but what you are telling me makes it sound more attractive to have a global logging counter. Comments? ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 26 12:44:34 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 8C64514EBD; Mon, 26 Jul 1999 12:44:24 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id NAA00579; Mon, 26 Jul 1999 13:44:16 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA20897; Mon, 26 Jul 1999 13:44:16 -0600 Date: Mon, 26 Jul 1999 13:44:16 -0600 Message-Id: <199907261944.NAA20897@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joe Greco Cc: dillon@apollo.backplane.com (Matthew Dillon), hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <199907261907.OAA08989@aurora.sol.net> References: <199907261847.LAA48202@apollo.backplane.com> <199907261907.OAA08989@aurora.sol.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > :So, I've a box that I have an ipfw ruleset on. The firewall should not be > > :changeable during runtime, and the box runs at securelevel=3. > > : > > :In order to prevent DoS disk-fill attacks, I also have specified > > :IPFW_VERBOSE_LIMIT. FWIW, as you pointed out below, this was put in specifically to avoid a DoS attack. > > :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, > > :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT > > :events and then you lose logging (ideally I'd zero nonzero rules once every > > :N minutes). > > : > > :Comments? > > > > Playing devil's advocate, someone might be using those counters for > > accounting purposes. That's about as worse a scenario as I can think > > of, and I can't imagine this sort of situation would be prevalient. > > > > I'd say that the counters should be clearable at high secure level. > > Then there should be a separate counter for logging purposes...? I do not > care if the accounting counters do not clear (ever), since things like MRTG > are designed to deal with that situation. MRTG? > However, it seems bad that you > would not be able to clear your counter for logging purposes, just in case > you actually _did_ mean that you want bad packets to be logged. *grin* > I will also note that it would be acceptable, to me at least, to maintain a > global (rather than per-rule) limit for the verbose limit. In general, I > would think that someone who uses the limit facility is trying to avoid a > DoS style disk-space attack. Agreed, see above. > Having a per-rule limit means that you > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit > (assuming an attacker exploits multiple rules) rather than a limit of > "IPFW_VERBOSE_LIMIT". I disagree. I have *tons* of firewall rules, and I don't want to have to recompile my kernel if I modify my script at a later point and make the rules 'more verbose'. Case in point, I may at one time want to 'log' all connections to a particular port, and then later ignore (no longer log) all the connections to that port *except* to a particular host. Or, the reverse may be true. In these cases, I don't want to have to recompile my kernel to allow 'more logging' of the information. I think a 'per-rule' limit works best, instead of a global limit. This also works well in the case of rootkit attempt breakins, since they tend to hit one rule multiple times, and then another multiple times, etc... With a 'global' limit, I may end up 'limiting out' on the first rule, and then miss all the rules hit later on with the attack. > It also makes it more difficult to code in a bunch > of "log" rules, since your periodic "zero" script has to know the number of > each one, and if you just do an "ipfw zero rule1 rule2 rule3...." then you > get a bunch of > > /kernel: ipfw: Entry rule1 cleared. > /kernel: ipfw: Entry rule2 cleared. > /kernel: ipfw: Entry rule3 cleared. > > each time you do this. Or, you do like I do, and have a cronjob 'zero' out the entire log ruleset everynight right after it sends the results to me to analyze. However, at times (during breakins I happen to catch, or during ruleset debugging sessions) I still want to have control over individual rules. > I would rather see something like > > /kernel: ipfw: logging limit reached, suspending. > # /sbin/ipfw zerolog > /kernel: ipfw: logging limit reset, resuming. This is essentially what I do. But, you can do 'ipfw zero' which accomplishes the same thing. However, this is really a side-issue. The last thing I'll say is that I think a 'global' counter is a bad idea, and this is from using IPFW for years in a real/deployed FreeBSD firewall situation. It would cause me more trouble than it's worth, and provide 'less' flexibility than currently exists (which I use). The real issue from your first email is '*should* ipfw rules be 'zero-able' at securelevel 3'. I'm of two minds. The paranoid administrator can't think of any bad things that could occur, but I can imagine something bad happening if someone were allowed to do this, although it's not completely concrete. I don't have the brain-cells to dedicate to thinking about the full implications of a 'bad-guy' zeroing out my rules. On the other, the firewall administrator who actually has to use this darn system is less worried about breakins and such, thinking that if someone compromised my system at high securelevels, they could do more damage to my system in other ways than by zeroing out my firewall numbers. But, then again if we're in securelevel 3, we shouldn't let *anyone* do anything to the system, since we're paranoid about anything negative happening to my system. In other words, I'm not sure what is the 'right' thing to do here. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 26 13:11: 4 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 6902A14C4C; Mon, 26 Jul 1999 13:10:58 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id PAA13453; Mon, 26 Jul 1999 15:10:45 -0500 (CDT) From: Joe Greco Message-Id: <199907262010.PAA13453@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907261944.NAA20897@mt.sri.com> from Nate Williams at "Jul 26, 1999 1:44:16 pm" To: nate@mt.sri.com (Nate Williams) Date: Mon, 26 Jul 1999 15:10:45 -0500 (CDT) Cc: jgreco@ns.sol.net, dillon@apollo.backplane.com, hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (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 > > > :So, I've a box that I have an ipfw ruleset on. The firewall should not be > > > :changeable during runtime, and the box runs at securelevel=3. > > > : > > > :In order to prevent DoS disk-fill attacks, I also have specified > > > :IPFW_VERBOSE_LIMIT. > > FWIW, as you pointed out below, this was put in specifically to avoid a > DoS attack. > > > > :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, > > > :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT > > > :events and then you lose logging (ideally I'd zero nonzero rules once every > > > :N minutes). > > > : > > > :Comments? > > > > > > Playing devil's advocate, someone might be using those counters for > > > accounting purposes. That's about as worse a scenario as I can think > > > of, and I can't imagine this sort of situation would be prevalient. > > > > > > I'd say that the counters should be clearable at high secure level. > > > > Then there should be a separate counter for logging purposes...? I do not > > care if the accounting counters do not clear (ever), since things like MRTG > > are designed to deal with that situation. > > MRTG? multi-router traffic grapher. Put a SNMP interface between that and ipfw and wheeee instant traffic graphing. > > However, it seems bad that you > > would not be able to clear your counter for logging purposes, just in case > > you actually _did_ mean that you want bad packets to be logged. > > *grin* > > > I will also note that it would be acceptable, to me at least, to maintain a > > global (rather than per-rule) limit for the verbose limit. In general, I > > would think that someone who uses the limit facility is trying to avoid a > > DoS style disk-space attack. > > Agreed, see above. > > > Having a per-rule limit means that you > > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit > > (assuming an attacker exploits multiple rules) rather than a limit of > > "IPFW_VERBOSE_LIMIT". > > I disagree. I have *tons* of firewall rules, and I don't want to have > to recompile my kernel if I modify my script at a later point and make > the rules 'more verbose'. Huh? I think you completely missed what I said - or maybe the opposite. Right now, if you have ten "log" rules, I can make your system log up to 10 * IPFW_VERBOSE_LIMIT rules (assuming I can generate violations for each rule). If you have 200 rules, it becomes 200 * IPFW_VERBOSE_LIMIT - again assuming I can generate appropriate violations. This eats up a grossly variable amount of disk space, which seems contrary to the whole concept of IPFW_VERBOSE_LIMIT. If I'm an admin, I'm going to think "Well lets see, I want to store a month of bad packets in it. I zero my counters every five minutes and there is a limit of 100 per five mins, and the average line length is 80 (or whatever) so therefore I need 80 * 100 * 12 * 24 * 30 or 70MB for my worst case scenario." Now given 200 rules, I can fill his disk in substantially less than a day. I don't know what you mean by "make the rules 'more verbose'" but what I am advocating is not any change in what currently exists... I am talking about limiting the number of entries possible in a manner that would seem to be more consistent with the intent behind IPFW_VERBOSE_LIMIT. > Case in point, I may at one time want to 'log' all connections to a > particular port, and then later ignore (no longer log) all the > connections to that port *except* to a particular host. Or, the reverse > may be true. In these cases, I don't want to have to recompile my > kernel to allow 'more logging' of the information. Huh? Why would you have to recompile your kernel? Assuming securelevel < 3, which is required regardless... you just delete the less restrictive rule and replace it with a more restrictive rule. What I am discussing does not affect this at all. If you are afraid of hitting the VERBOSE_LIMIT, that is why you would have an additional command such as "ipfw zerolog". > I think a 'per-rule' limit works best, instead of a global limit. This > also works well in the case of rootkit attempt breakins, since they tend > to hit one rule multiple times, and then another multiple times, etc... > > With a 'global' limit, I may end up 'limiting out' on the first rule, > and then miss all the rules hit later on with the attack. Yes, you might. But you might miss them anyways, and I can run you out of disk space quicker. > > It also makes it more difficult to code in a bunch > > of "log" rules, since your periodic "zero" script has to know the number of > > each one, and if you just do an "ipfw zero rule1 rule2 rule3...." then you > > get a bunch of > > > > /kernel: ipfw: Entry rule1 cleared. > > /kernel: ipfw: Entry rule2 cleared. > > /kernel: ipfw: Entry rule3 cleared. > > > > each time you do this. > > Or, you do like I do, and have a cronjob 'zero' out the entire log > ruleset everynight right after it sends the results to me to analyze. Interferes with your accounting counters. You need to be able to do them individually to avoid that. > However, at times (during breakins I happen to catch, or during ruleset > debugging sessions) I still want to have control over individual rules. > > > I would rather see something like > > > > /kernel: ipfw: logging limit reached, suspending. > > # /sbin/ipfw zerolog > > /kernel: ipfw: logging limit reset, resuming. > > This is essentially what I do. But, you can do 'ipfw zero' which > accomplishes the same thing. No, it nukes the accounting counters. > However, this is really a side-issue. The last thing I'll say is that I > think a 'global' counter is a bad idea, and this is from using IPFW for > years in a real/deployed FreeBSD firewall situation. It would cause me > more trouble than it's worth, and provide 'less' flexibility than > currently exists (which I use). Then your argument devolves down to one of wanting a per-rule counter and you don't care if it is the accounting one or a new one... And I've been using FreeBSD and IPFW in a real/deployed environment as well, and I keep hitting up against these goofy sorts of problems. It is much, much more usable than something like ipfw in 2.1R or earlier, but these little things still matter. > The real issue from your first email is '*should* ipfw rules be > 'zero-able' at securelevel 3'. I'm of two minds. The paranoid > administrator can't think of any bad things that could occur, but I can > imagine something bad happening if someone were allowed to do this, > although it's not completely concrete. I don't have the brain-cells to > dedicate to thinking about the full implications of a 'bad-guy' zeroing > out my rules. He interferes with whatever other features you've built into the system which rely on those accounting numbers. I agree - you probably don't want to do that. > On the other, the firewall administrator who actually has to use this > darn system is less worried about breakins and such, thinking that if > someone compromised my system at high securelevels, they could do more > damage to my system in other ways than by zeroing out my firewall > numbers. > > But, then again if we're in securelevel 3, we shouldn't let *anyone* do > anything to the system, since we're paranoid about anything negative > happening to my system. > > In other words, I'm not sure what is the 'right' thing to do here. Well, the 'right' thing is clear: pull the limit count out of the accounting count. This solves both the problem of zeroing accounting counters and potentially messing with other things, and also of letting people do anything 'negative' in securelevel 3. By pulling the limit count out into a separate entity, nothing 'negative' can happen (because stopping the logging process is definitely negative, and being able to restart it without messing with other stuff is positive). Now that we are agreed that the limit count needs to be divorced from the accounting count, we can debate whether it should be a per-rule or global limit. Maybe it could be sysctl'able... ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 26 13:48:36 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id D1BA214FDD; Mon, 26 Jul 1999 13:48:26 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id OAA01379; Mon, 26 Jul 1999 14:45:14 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA21485; Mon, 26 Jul 1999 14:45:13 -0600 Date: Mon, 26 Jul 1999 14:45:13 -0600 Message-Id: <199907262045.OAA21485@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joe Greco Cc: nate@mt.sri.com (Nate Williams), dillon@apollo.backplane.com, hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <199907262010.PAA13453@aurora.sol.net> References: <199907261944.NAA20897@mt.sri.com> <199907262010.PAA13453@aurora.sol.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Having a per-rule limit means that you > > > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit > > > (assuming an attacker exploits multiple rules) rather than a limit of > > > "IPFW_VERBOSE_LIMIT". > > > > I disagree. I have *tons* of firewall rules, and I don't want to have > > to recompile my kernel if I modify my script at a later point and make > > the rules 'more verbose'. > > Huh? > > I think you completely missed what I said - or maybe the opposite. > > Right now, if you have ten "log" rules, I can make your system log up > to 10 * IPFW_VERBOSE_LIMIT rules (assuming I can generate violations for > each rule). If you have 200 rules, it becomes 200 * IPFW_VERBOSE_LIMIT - > again assuming I can generate appropriate violations. > > This eats up a grossly variable amount of disk space, which seems contrary > to the whole concept of IPFW_VERBOSE_LIMIT. If I'm getting attacked such that I'm logging data, I *want* as much information on the attack as possible. I realize this when I setup my IPFW_VERBOSE_LIMIT 'limits' as well as the logging rules. If an attack takes is 1 rule 100 times, and the other 10 rules 1 time, I'd like to see all of this. With a 'global' limit set to 100, I wouldn't see these kinds of hits. Also, from analyzing attacks for years, most attacks have a pattern that is *best* seen from seeing it hit a number of rules. By settin a per-rule limit, you 'generally' can determine that an attack is going to have a signature the same as the previous 'n' hits on that rule, but you want to see the rest of the attack. I don't care to see a scan of the IMAP 1000 times when right after they finish scanning it they also try to attack my POP3 port 1000 times. Rather, I'd rather see the first 100 attempts on the IMAP port, then the first 100 attempts on POP3, then the first 100 attempts on port 7, etc... You get *better* information on per-rule limits than on a global limit. > If I'm an admin, I'm going to think "Well lets see, I want to store a > month of bad packets in it. If you're an admin on today's internet, you'd realize that there is *NO* way to get save a month worth of bad packets. Heck, at least once/week I can't even store a day's worth of bad packets (I assume when we say bad packets, we're talking about the > I zero > my counters every five minutes and there is a limit of 100 per five mins, > and the average line length is 80 (or whatever) so therefore I need 80 * 100 > * 12 * 24 * 30 or 70MB for my worst case scenario." Not. If the attack is the same, then the syslog error reporting will same something like (this is a real message, with IP addresses change to protect the guilty..): Jun 29 16:43:09 ns /kernel: ipfw: 64000 Deny UDP 1.2.3.4:53 4.3.2.1:54927 out via ed0 Jun 29 16:43:44 ns last message repeated 3 times If you've got seperate attacks, then you've got too much stuff you're logging. > Now given 200 rules, I can fill his disk in substantially less than a day. If you're logging that much information, then you're logging too much information. In any case, you've got information overload, so adding a global limit on the rules means you're losing as much (or more) information than you're logging, which is just as bad (or worse). If you're worried about logging too much information, then don't reset your counters every 5 minutes. Besides, you're losing information if you're max'd out every 5 minutes anyway, so it really doesn't matter when you zero out your counters. > I don't know what you mean by "make the rules 'more verbose'" but what I > am advocating is not any change in what currently exists... I am talking > about limiting the number of entries possible in a manner that would seem > to be more consistent with the intent behind IPFW_VERBOSE_LIMIT. IPFW_VERBOSE_LIMIT is a per/rule limit. This is what is intended. Most attacks don't hit the entire system on every rule in order to do a DoS attack. Even so, each rule with eventually 'limit-out' and the system will no longer log packets. This is a 'bad thing' from a security standpoint, since at that point we are losing information. The idea behind IPFW_VERBOSE_LIMIT is to avoid DoS attacks, while still allowing *MAXIMUM* data collection when a DoS attack is not happening. It's not there to make your logfiles small. If you want small logfiles, turn of IPFW logging altogether. (I'm actually serious here.) > > Case in point, I may at one time want to 'log' all connections to a > > particular port, and then later ignore (no longer log) all the > > connections to that port *except* to a particular host. Or, the reverse > > may be true. In these cases, I don't want to have to recompile my > > kernel to allow 'more logging' of the information. > > Huh? Why would you have to recompile your kernel? Assuming securelevel < > 3, which is required regardless... you just delete the less restrictive > rule and replace it with a more restrictive rule. I want *both* rules, and I want *full* information disclosure since I want to know how I'm being attacked. See, knowing how I'm attacked is useful since it helps me avoid future attacks, as well as allow me potentially stock future attacks from happening by informing an ISP of the behavior of one of their users. Maybe that person will get on another ISP, or maybe he'll cleanup his act. Who knows, but sitting idle means nothing happens. > > I think a 'per-rule' limit works best, instead of a global limit. This > > also works well in the case of rootkit attempt breakins, since they tend > > to hit one rule multiple times, and then another multiple times, etc... > > > > With a 'global' limit, I may end up 'limiting out' on the first rule, > > and then miss all the rules hit later on with the attack. > > Yes, you might. But you might miss them anyways, and I can run you out of > disk space quicker. Sure, but you have to know alot about my box to do that, and if you have that kind of information, I can run your box out of disk space just as easily, it takes a bit longer. (And, it would take you months to run my box out of disk space in it's current setup, which is a engineering tradeoff for maximum information retrieval balanced with the history of attacks on my system, along with engineering paranoia about how a DoS attack could occur.) Again, IPFW_VERBOSE_LIMIT is *NOT* there to make for smaller logfiles, it's there to avoid a single kind of attack made on the system. These kinds of attacks 'tend' to focus on a single port and/or rule. Also, having a global count also leaves you 'wide-open' for doing a DoS attack, following by a real attack. You would no longer have any idea how the 'real' attack is occuring, so with the current implementation, the attacker must know your exact FW configuration in order to attack you well. (And, I would argue that *IF* they had my FW configuration and/or rulesets, my firewall would be almost useless since in any system, there are tradeoffs made for 'ease-of-use' vs. security.) > > > It also makes it more difficult to code in a bunch > > > of "log" rules, since your periodic "zero" script has to know the number of > > > each one, and if you just do an "ipfw zero rule1 rule2 rule3...." then you > > > get a bunch of > > > > > > /kernel: ipfw: Entry rule1 cleared. > > > /kernel: ipfw: Entry rule2 cleared. > > > /kernel: ipfw: Entry rule3 cleared. > > > > > > each time you do this. > > > > Or, you do like I do, and have a cronjob 'zero' out the entire log > > ruleset everynight right after it sends the results to me to analyze. > > Interferes with your accounting counters. You need to be able to do > them individually to avoid that. I'm not disagreeing. ipfw zero rule1 also interfers with your counters as well, but only on those rules. > > However, at times (during breakins I happen to catch, or during ruleset > > debugging sessions) I still want to have control over individual rules. > > > > > I would rather see something like > > > > > > /kernel: ipfw: logging limit reached, suspending. > > > # /sbin/ipfw zerolog > > > /kernel: ipfw: logging limit reset, resuming. > > > > This is essentially what I do. But, you can do 'ipfw zero' which > > accomplishes the same thing. > > No, it nukes the accounting counters. I've not argued that point. > > However, this is really a side-issue. The last thing I'll say is that I > > think a 'global' counter is a bad idea, and this is from using IPFW for > > years in a real/deployed FreeBSD firewall situation. It would cause me > > more trouble than it's worth, and provide 'less' flexibility than > > currently exists (which I use). > > Then your argument devolves down to one of wanting a per-rule counter and > you don't care if it is the accounting one or a new one... Correct. The existing infrastructure works for me. I don't use my FW for accounting purposes (that's what the wireless bridge is for), so I don't care if the counters are zero'd. But, I *don't* want to see the system modified to replace the per-rule counters with a global counter since it has some exteremely negative side-effects, the most obnoxious is to lose 'valid' breakin information, which is the point of having logging in the first place. > And I've been using FreeBSD and IPFW in a real/deployed environment as well, > and I keep hitting up against these goofy sorts of problems. It is much, > much more usable than something like ipfw in 2.1R or earlier, but these > little things still matter. The changes in 2.1 affected quite a bit, but all it required me to do was to rewrite my FW rules. I saw very little 'functionality' additions, just changes made that required me to re-write how I was doing things. Since the firewall is a 'side' job of mine, it was a pain in the butt to do it, but now that's (long) past. :) > > The real issue from your first email is '*should* ipfw rules be > > 'zero-able' at securelevel 3'. I'm of two minds. The paranoid > > administrator can't think of any bad things that could occur, but I can > > imagine something bad happening if someone were allowed to do this, > > although it's not completely concrete. I don't have the brain-cells to > > dedicate to thinking about the full implications of a 'bad-guy' zeroing > > out my rules. > > He interferes with whatever other features you've built into the system > which rely on those accounting numbers. I agree - you probably don't > want to do that. One could argue that accounting numbers in a firewall shouldn't be trusted, but I won't argue that point since the firewall is often the most 'natural' place to stick network accounting software. > Well, the 'right' thing is clear: pull the limit count out of the > accounting count. This solves both the problem of zeroing accounting > counters and potentially messing with other things, and also of letting > people do anything 'negative' in securelevel 3. Is it the 'right' thing to do? I think that someone messing with the 'logging' rule counts could be just as dangerous as someone messing with the accounting counts. Again, if you're paranoid enough to have securelevel 3, you've got to be paranoid enough to assume that someone *HAS* root access on your box, and is going to do anything nasty they could. > By pulling the limit count out into a separate entity, nothing > 'negative' can happen (because stopping the logging process is > definitely negative, and being able to restart it without messing with > other stuff is positive). I'm not sure this is an acceptable change either, but I'll leave that discussion to the networking folks. > Now that we are agreed that the limit count needs to be divorced from the > accounting count, we can debate whether it should be a per-rule or global > limit. Hold on to your horses, Hoss. I haven't agreed to that. Don't be putting words in my mouth. :) :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 26 14:39:34 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id C2EA014A09; Mon, 26 Jul 1999 14:39:12 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id QAA19479; Mon, 26 Jul 1999 16:36:29 -0500 (CDT) From: Joe Greco Message-Id: <199907262136.QAA19479@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907262045.OAA21485@mt.sri.com> from Nate Williams at "Jul 26, 1999 2:45:13 pm" To: nate@mt.sri.com (Nate Williams) Date: Mon, 26 Jul 1999 16:36:28 -0500 (CDT) Cc: jgreco@ns.sol.net, nate@mt.sri.com, dillon@apollo.backplane.com, hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (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 > > > > Having a per-rule limit means that you > > > > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit > > > > (assuming an attacker exploits multiple rules) rather than a limit of > > > > "IPFW_VERBOSE_LIMIT". > > > > > > I disagree. I have *tons* of firewall rules, and I don't want to have > > > to recompile my kernel if I modify my script at a later point and make > > > the rules 'more verbose'. > > > > Huh? > > > > I think you completely missed what I said - or maybe the opposite. > > > > Right now, if you have ten "log" rules, I can make your system log up > > to 10 * IPFW_VERBOSE_LIMIT rules (assuming I can generate violations for > > each rule). If you have 200 rules, it becomes 200 * IPFW_VERBOSE_LIMIT - > > again assuming I can generate appropriate violations. > > > > This eats up a grossly variable amount of disk space, which seems contrary > > to the whole concept of IPFW_VERBOSE_LIMIT. > > If I'm getting attacked such that I'm logging data, I *want* as much > information on the attack as possible. I realize this when I setup my > IPFW_VERBOSE_LIMIT 'limits' as well as the logging rules. > > If an attack takes is 1 rule 100 times, and the other 10 rules 1 time, > I'd like to see all of this. With a 'global' limit set to 100, I > wouldn't see these kinds of hits. > > Also, from analyzing attacks for years, most attacks have a pattern that > is *best* seen from seeing it hit a number of rules. By settin a > per-rule limit, you 'generally' can determine that an attack is going to > have a signature the same as the previous 'n' hits on that rule, but you > want to see the rest of the attack. > > I don't care to see a scan of the IMAP 1000 times when right after they > finish scanning it they also try to attack my POP3 port 1000 times. > Rather, I'd rather see the first 100 attempts on the IMAP port, then the > first 100 attempts on POP3, then the first 100 attempts on port 7, > etc... > > You get *better* information on per-rule limits than on a global limit. No, you simply get a finer-grained ability to select. > > If I'm an admin, I'm going to think "Well lets see, I want to store a > > month of bad packets in it. > > If you're an admin on today's internet, you'd realize that there is *NO* > way to get save a month worth of bad packets. Heck, at least once/week > I can't even store a day's worth of bad packets (I assume when we say > bad packets, we're talking about the If I'm an admin on today's internet (and I am), of course I realize that I'm not going to save a month worth of all bad packets, but I _can_ choose to hold onto a reasonable amount of logging information, which is what we are discussing. That is part of the _point_ of the IPFW_VERBOSE_LIMIT option... it allows you to sample the beginning of each 5 minute period, and you ought to be able to calculate the space required in a manner that allows you to guarantee that you have sufficient space. Now, if you're on an OC3c and you want to set IPFW_VERBOSE_LIMIT to 100000, and you reset the counter every 5 minutes, you still _ought_ to be able to determine that you require 2GB of disk space per day to keep those records. (And if you're getting 100K rejectable packets every 5 minutes, something is seriously wrong) > > I zero > > my counters every five minutes and there is a limit of 100 per five mins, > > and the average line length is 80 (or whatever) so therefore I need 80 * 100 > > * 12 * 24 * 30 or 70MB for my worst case scenario." > > Not. If the attack is the same, then the syslog error reporting will > same something like (this is a real message, with IP addresses change to > protect the guilty..): > > Jun 29 16:43:09 ns /kernel: ipfw: 64000 Deny UDP 1.2.3.4:53 4.3.2.1:54927 out via ed0 > Jun 29 16:43:44 ns last message repeated 3 times > > If you've got seperate attacks, then you've got too much stuff you're > logging. > > > Now given 200 rules, I can fill his disk in substantially less than a day. > > If you're logging that much information, then you're logging too much > information. In any case, you've got information overload, so adding a > global limit on the rules means you're losing as much (or more) > information than you're logging, which is just as bad (or worse). No. You're not necessarily logging too much information. I do log a whole bunch of shouldn't-happen scenarios, because if they do happen, it means something is either horribly broken or somebody is doing something horribly wrong. I don't want an event such as an outbound source 10-net address to happen... in theory it can't because I filter at my borders and use no 10-net stuff internally. But I damn well want to know if it happens ANYWAYS. > If you're worried about logging too much information, then don't reset > your counters every 5 minutes. Besides, you're losing information if > you're max'd out every 5 minutes anyway, so it really doesn't matter > when you zero out your counters. You just argued my point for me, thank you. I _want_ to see the things that I choose to log, and by definition once I pass IPFW_VERBOSE_LIMIT, then the information is beyond the point of being useful. > > I don't know what you mean by "make the rules 'more verbose'" but what I > > am advocating is not any change in what currently exists... I am talking > > about limiting the number of entries possible in a manner that would seem > > to be more consistent with the intent behind IPFW_VERBOSE_LIMIT. > > IPFW_VERBOSE_LIMIT is a per/rule limit. This is what is intended. Most > attacks don't hit the entire system on every rule in order to do a DoS > attack. Even so, each rule with eventually 'limit-out' and the system > will no longer log packets. This is a 'bad thing' from a security > standpoint, since at that point we are losing information. Okay, so what YOU really want is to not set up an IPFW_VERBOSE_LIMIT at all, and that's perfectly valid as well. > The idea behind IPFW_VERBOSE_LIMIT is to avoid DoS attacks, while still > allowing *MAXIMUM* data collection when a DoS attack is not happening. > > It's not there to make your logfiles small. If you want small logfiles, > turn of IPFW logging altogether. > > (I'm actually serious here.) Oh, that's a f'ing crock. What _I_ really want is to be able to GET the god damn information when the system is in securemode 3 and the damn IPFW has stopped logging due to the VERBOSE_LIMIT. You think I'm interested in turning OFF IPFW logging? You're nuts if you think so. I need to be able to log a reasonable number of things without logging so many that it turns into a DoS attack. I'm trying to figure out how to do that while retaining (or increasing) intended functionality - because I've clearly spelled out a broken (but quite legitimate) situation. The stated rationale behind adding VERBOSE_LIMIT, when it was added, was to reduce or eliminate the chance of a DoS attack. Now, the best way to eliminate the chance of a DoS attack is _algorithmically_. Giving someone a mechanism that allows them to determine the maximum resource commitment for a given scenario eliminates the chance for that DoS attack. Giving someone a mechanism that may use a variable quantity of resources is the typical programming practice that leads to a resource starvation DoS. In my own scenario, what I'm trying to do is to log a reasonable amount of stuff when something "odd" happens. I don't want someone to be able to take down my syslogd, but logging a hundred events every five minutes is not going to result in that. I can increase that number to whatever I feel is needed to make me "comfortable" that I will catch sufficient information about an incident. I also want to be able to catch multiple instances... so if someone attacks my server a half hour later, I need that counter to have been zero'ed (and I can presumably determine whether or not any new data is part of the previous attack or a new attack). I also want it to be completely automatic, so that if someone attacks my server while I'm asleep on the console, the machine does a reasonable job of trying to catch the information. What I absolutely need is a way to clear out the VERBOSE_LIMIT counter. If it is one counter, that is trivial. If it is a per-rule counter, I can at least write a C program to DTRT quickly via the ipfirewall ioctl interface. Just turning off logging is NOT a cool thing to suggest, unless you would not mind me suggesting that you don't need a firewall. > > > Case in point, I may at one time want to 'log' all connections to a > > > particular port, and then later ignore (no longer log) all the > > > connections to that port *except* to a particular host. Or, the reverse > > > may be true. In these cases, I don't want to have to recompile my > > > kernel to allow 'more logging' of the information. > > > > Huh? Why would you have to recompile your kernel? Assuming securelevel < > > 3, which is required regardless... you just delete the less restrictive > > rule and replace it with a more restrictive rule. > > I want *both* rules, and I want *full* information disclosure since I > want to know how I'm being attacked. See, knowing how I'm attacked is > useful since it helps me avoid future attacks, as well as allow me > potentially stock future attacks from happening by informing an ISP of > the behavior of one of their users. Maybe that person will get on > another ISP, or maybe he'll cleanup his act. Who knows, but sitting > idle means nothing happens. Okay, so you put in both rules. It doesn't matter. What stops you from doing # sysctl -w net.inet.ip.fw.verbose_limit=0 net.inet.ip.fw.verbose_limit: 100 -> 0 to temporarily remove the limit entirely, thereby allowing both entries to log? > > > I think a 'per-rule' limit works best, instead of a global limit. This > > > also works well in the case of rootkit attempt breakins, since they tend > > > to hit one rule multiple times, and then another multiple times, etc... > > > > > > With a 'global' limit, I may end up 'limiting out' on the first rule, > > > and then miss all the rules hit later on with the attack. > > > > Yes, you might. But you might miss them anyways, and I can run you out of > > disk space quicker. > > Sure, but you have to know alot about my box to do that, and if you have > that kind of information, I can run your box out of disk space just as > easily, it takes a bit longer. > > (And, it would take you months to run my box out of disk space in it's > current setup, which is a engineering tradeoff for maximum information > retrieval balanced with the history of attacks on my system, along with > engineering paranoia about how a DoS attack could occur.) > > Again, IPFW_VERBOSE_LIMIT is *NOT* there to make for smaller logfiles, > it's there to avoid a single kind of attack made on the system. These > kinds of attacks 'tend' to focus on a single port and/or rule. Also, > having a global count also leaves you 'wide-open' for doing a DoS > attack, following by a real attack. You would no longer have any idea > how the 'real' attack is occuring, so with the current implementation, > the attacker must know your exact FW configuration in order to attack > you well. (And, I would argue that *IF* they had my FW configuration > and/or rulesets, my firewall would be almost useless since in any > system, there are tradeoffs made for 'ease-of-use' vs. security.) I'm not arguing for smaller logfiles. You don't tell a person with a several gigabyte /var about how they are arguing for smaller logfiles. I'm looking strictly at the intended purpose of IPFW_VERBOSE_LIMIT. > > > > It also makes it more difficult to code in a bunch > > > > of "log" rules, since your periodic "zero" script has to know the number of > > > > each one, and if you just do an "ipfw zero rule1 rule2 rule3...." then you > > > > get a bunch of > > > > > > > > /kernel: ipfw: Entry rule1 cleared. > > > > /kernel: ipfw: Entry rule2 cleared. > > > > /kernel: ipfw: Entry rule3 cleared. > > > > > > > > each time you do this. > > > > > > Or, you do like I do, and have a cronjob 'zero' out the entire log > > > ruleset everynight right after it sends the results to me to analyze. > > > > Interferes with your accounting counters. You need to be able to do > > them individually to avoid that. > > I'm not disagreeing. ipfw zero rule1 also interfers with your counters > as well, but only on those rules. I count on separate rules right now. :-/ > > > However, at times (during breakins I happen to catch, or during ruleset > > > debugging sessions) I still want to have control over individual rules. > > > > > > > I would rather see something like > > > > > > > > /kernel: ipfw: logging limit reached, suspending. > > > > # /sbin/ipfw zerolog > > > > /kernel: ipfw: logging limit reset, resuming. > > > > > > This is essentially what I do. But, you can do 'ipfw zero' which > > > accomplishes the same thing. > > > > No, it nukes the accounting counters. > > I've not argued that point. > > > > However, this is really a side-issue. The last thing I'll say is that I > > > think a 'global' counter is a bad idea, and this is from using IPFW for > > > years in a real/deployed FreeBSD firewall situation. It would cause me > > > more trouble than it's worth, and provide 'less' flexibility than > > > currently exists (which I use). > > > > Then your argument devolves down to one of wanting a per-rule counter and > > you don't care if it is the accounting one or a new one... > > Correct. The existing infrastructure works for me. I don't use my FW > for accounting purposes (that's what the wireless bridge is for), so I > don't care if the counters are zero'd. But, I *don't* want to see the > system modified to replace the per-rule counters with a global counter > since it has some exteremely negative side-effects, the most obnoxious > is to lose 'valid' breakin information, which is the point of having > logging in the first place. Well, you certainly lose it now, anyways, with securelevel >= 3 unless you happen to be made aware of the attack in some other manner, because once you hit IPFW_VERBOSE_LIMIT, the system just stops logging. You haven't provided any helpful suggestions about how to deal with this. You can argue that you want per-rule limits, and you've done so, but I think it is safe to say that both ways have merits. > > And I've been using FreeBSD and IPFW in a real/deployed environment as well, > > and I keep hitting up against these goofy sorts of problems. It is much, > > much more usable than something like ipfw in 2.1R or earlier, but these > > little things still matter. > > The changes in 2.1 affected quite a bit, but all it required me to do > was to rewrite my FW rules. I saw very little 'functionality' > additions, just changes made that required me to re-write how I was > doing things. Since the firewall is a 'side' job of mine, it was a pain > in the butt to do it, but now that's (long) past. :) > > > > The real issue from your first email is '*should* ipfw rules be > > > 'zero-able' at securelevel 3'. I'm of two minds. The paranoid > > > administrator can't think of any bad things that could occur, but I can > > > imagine something bad happening if someone were allowed to do this, > > > although it's not completely concrete. I don't have the brain-cells to > > > dedicate to thinking about the full implications of a 'bad-guy' zeroing > > > out my rules. > > > > He interferes with whatever other features you've built into the system > > which rely on those accounting numbers. I agree - you probably don't > > want to do that. > > One could argue that accounting numbers in a firewall shouldn't be > trusted, but I won't argue that point since the firewall is often the > most 'natural' place to stick network accounting software. If you can't trust something in the kernel, then you just can't trust anything at all. > > Well, the 'right' thing is clear: pull the limit count out of the > > accounting count. This solves both the problem of zeroing accounting > > counters and potentially messing with other things, and also of letting > > people do anything 'negative' in securelevel 3. > > Is it the 'right' thing to do? I think that someone messing with the > 'logging' rule counts could be just as dangerous as someone messing with > the accounting counts. It is no more dangerous, and somebody zeroing (the only thing they should be able to do!) the logging rule counts would result in additional logging going on... this might mess up any sort of deterministic disk space calculation that you had going on, but if it was really an issue, you could also set up a sysctl variable or kernel #define that would forbid even this - which lands you back right where we are, if you choose that, but gives everyone else who needs it the option to do automated logging. > Again, if you're paranoid enough to have securelevel 3, you've got to be > paranoid enough to assume that someone *HAS* root access on your box, > and is going to do anything nasty they could. Yes, but causing additional logging to happen is going to be something that is likely to _attract_ my attention. > > By pulling the limit count out into a separate entity, nothing > > 'negative' can happen (because stopping the logging process is > > definitely negative, and being able to restart it without messing with > > other stuff is positive). > > I'm not sure this is an acceptable change either, but I'll leave that > discussion to the networking folks. > > > Now that we are agreed that the limit count needs to be divorced from the > > accounting count, we can debate whether it should be a per-rule or global > > limit. > > Hold on to your horses, Hoss. I haven't agreed to that. Don't be > putting words in my mouth. :) :) Well, then, how do you "fix" this problem? ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 26 19:58:44 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 797E414BEC; Mon, 26 Jul 1999 19:58:38 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id WAA36713; Mon, 26 Jul 1999 22:56:17 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Mon, 26 Jul 1999 22:56:17 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Joe Greco Cc: Matthew Dillon , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907261907.OAA08989@aurora.sol.net> 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 Instead of zeroing it, how about raising the logging limit to (current + whatever the limit was) Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 26 20: 8:20 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C1DD914BFF; Mon, 26 Jul 1999 20:08:17 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA49737; Mon, 26 Jul 1999 20:07:38 -0700 (PDT) (envelope-from dillon) Date: Mon, 26 Jul 1999 20:07:38 -0700 (PDT) From: Matthew Dillon Message-Id: <199907270307.UAA49737@apollo.backplane.com> To: "Brian F. Feldman" Cc: Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero References: Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Instead of zeroing it, how about raising the logging limit to (current + :whatever the limit was) : : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ : green@FreeBSD.org _ __ ___ | _ ) __| \ The way I see it either some piece of software is monitor the counters, in which case the sysad does not need to clear them and does not need to look at log messages, or the sysad is monitoring the stuff manually and using the log messages. In the one case the counters don't need to be cleared (and, indeed, should not be), in the other case the sysad may want to clear them due to the manual monitoring. What we are really discussing here is the use of ipfw's counters in an unsophisticated setup. The sophisticated setup is already handled. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 26 20:15: 9 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 89F8114CF7; Mon, 26 Jul 1999 20:15:05 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id XAA37091; Mon, 26 Jul 1999 23:12:37 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Mon, 26 Jul 1999 23:12:37 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Matthew Dillon Cc: Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907270307.UAA49737@apollo.backplane.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 Mon, 26 Jul 1999, Matthew Dillon wrote: > > :Instead of zeroing it, how about raising the logging limit to (current + > :whatever the limit was) > : > : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ > : green@FreeBSD.org _ __ ___ | _ ) __| \ > > The way I see it either some piece of software is monitor the counters, > in which case the sysad does not need to clear them and does not need to > look at log messages, or the sysad is monitoring the stuff manually and > using the log messages. In the one case the counters don't need to be > cleared (and, indeed, should not be), in the other case the sysad may > want to clear them due to the manual monitoring. > > What we are really discussing here is the use of ipfw's counters in an > unsophisticated setup. The sophisticated setup is already handled. That doesn't mean we shouldn't allow people to have an unsophisticated setup, just because a sophisticated one is available. It would be useful to have a per-firewall-rule counter, decrement it on each match if logging and set, and be able to reset to something higher. > > -Matt > Matthew Dillon > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 26 20:16:46 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 0157115189; Mon, 26 Jul 1999 20:16:43 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA49808; Mon, 26 Jul 1999 20:16:39 -0700 (PDT) (envelope-from dillon) Date: Mon, 26 Jul 1999 20:16:39 -0700 (PDT) From: Matthew Dillon Message-Id: <199907270316.UAA49808@apollo.backplane.com> To: "Brian F. Feldman" Cc: Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero References: Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :That doesn't mean we shouldn't allow people to have an unsophisticated setup, :just because a sophisticated one is available. It would be useful to have :a per-firewall-rule counter, decrement it on each match if logging and :set, and be able to reset to something higher. : : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ There may be some confusion here. I am advocating that we *allow* the zeroing of counters at secure level 3. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 26 20:23:42 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 5A41014CF7; Mon, 26 Jul 1999 20:23:38 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id XAA37317; Mon, 26 Jul 1999 23:22:25 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Mon, 26 Jul 1999 23:22:24 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Matthew Dillon Cc: Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907270316.UAA49808@apollo.backplane.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 Mon, 26 Jul 1999, Matthew Dillon wrote: > > :That doesn't mean we shouldn't allow people to have an unsophisticated setup, > :just because a sophisticated one is available. It would be useful to have > :a per-firewall-rule counter, decrement it on each match if logging and > :set, and be able to reset to something higher. > : > : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ > > There may be some confusion here. I am advocating that we *allow* the > zeroing of counters at secure level 3. Which is what I am advocating against. > > -Matt > Matthew Dillon > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 26 20:42:59 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id E99EB151CC; Mon, 26 Jul 1999 20:42:56 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id UAA82669; Mon, 26 Jul 1999 20:42:21 -0700 (PDT) Date: Mon, 26 Jul 1999 20:42:20 -0700 (PDT) From: Julian Elischer To: "Brian F. Feldman" Cc: Matthew Dillon , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: 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 I like the ability at secure level 3 to only reset the counters forward.. It fits in with such things as the "append only" flag. Maybe a new keyword. "advance" julian On Mon, 26 Jul 1999, Brian F. Feldman wrote: > On Mon, 26 Jul 1999, Matthew Dillon wrote: > > > > > :That doesn't mean we shouldn't allow people to have an unsophisticated setup, > > :just because a sophisticated one is available. It would be useful to have > > :a per-firewall-rule counter, decrement it on each match if logging and > > :set, and be able to reset to something higher. > > : > > : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ > > > > There may be some confusion here. I am advocating that we *allow* the > > zeroing of counters at secure level 3. > > Which is what I am advocating against. > > > > > -Matt > > Matthew Dillon > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-ipfw" in the body of the message > > > > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ > green@FreeBSD.org _ __ ___ | _ ) __| \ > FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | > http://www.FreeBSD.org/ _ |___/___/___/ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" 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 Mon Jul 26 20:51:29 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 45DF1151CC; Mon, 26 Jul 1999 20:51:26 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA49943; Mon, 26 Jul 1999 20:48:28 -0700 (PDT) (envelope-from dillon) Date: Mon, 26 Jul 1999 20:48:28 -0700 (PDT) From: Matthew Dillon Message-Id: <199907270348.UAA49943@apollo.backplane.com> To: "Brian F. Feldman" Cc: Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero References: Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> :> :That doesn't mean we shouldn't allow people to have an unsophisticated setup, :> :just because a sophisticated one is available. It would be useful to have :> :a per-firewall-rule counter, decrement it on each match if logging and :> :set, and be able to reset to something higher. :> : :> : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ :> :> There may be some confusion here. I am advocating that we *allow* the :> zeroing of counters at secure level 3. : :Which is what I am advocating against. Let me put it a different way: ipfw allows you to clear counters. It is a feature that already exists. However, it does not allow you to do it if you are sitting at secure level 3. Why not? I can't think of any good reason why clearing the counters should be disallowed when sitting at a higher secure level. The counters are nothing more then statistics. Clearing statistics is not a security threat. The discussion should simply be about that. Not all this garbage about adding new features. There's a feature that does not seem to impact security, secure level disallows it, why? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 0:38:48 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from donpac.ru (nsnew.donpac.ru [195.161.172.254]) by hub.freebsd.org (Postfix) with ESMTP id 2B3F51533E; Tue, 27 Jul 1999 00:38:28 -0700 (PDT) (envelope-from hitower@don.sitek.net) Received: from dkeeper.ddns.org (ppp1.ats74.donpac.ru [195.161.173.192]) by donpac.ru (8.9.1/8.9.1/cae1.1.0.4) with ESMTP id LAA04696; Tue, 27 Jul 1999 11:38:48 GMT Received: from don.sitek.net (nest.dungeon [10.0.0.254]) by dkeeper.ddns.org (8.9.2/8.9.1) with ESMTP id LAA21385; Tue, 27 Jul 1999 11:37:12 +0400 (MSD) (envelope-from hitower@don.sitek.net) Message-ID: <379D60D9.2620590F@don.sitek.net> Date: Tue, 27 Jul 1999 11:33:45 +0400 From: Max Mukhin X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Joe Greco Cc: freebsd-hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero References: <199907261816.NAA05470@aurora.sol.net> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Joe Greco wrote: > > Hello, > > So, I've a box that I have an ipfw ruleset on. The firewall should not be > changeable during runtime, and the box runs at securelevel=3. > > In order to prevent DoS disk-fill attacks, I also have specified > IPFW_VERBOSE_LIMIT. > > Now, the problem is, in securelevel 3, you cannot zero a rule's counter, > so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT > events and then you lose logging (ideally I'd zero nonzero rules once every > N minutes). how about newsyslog? it will save space a much, i think > > Comments? > > ... Joe > > ------------------------------------------------------------------------------- > Joe Greco - Systems Administrator jgreco@ns.sol.net > Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message -- hitower@don.sitek.net | ICQ 21050590 | Rostov-on-Don, Russia -----------------------+--------------+-------------------------------- PGP fingerprint: 2E26 C4FF 6940 1F7E 0188 1684 7B21 CF13 068D AE82 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 4:52:46 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from mpp.pro-ns.net (mpp.pro-ns.net [208.200.182.72]) by hub.freebsd.org (Postfix) with ESMTP id 04AED153B8; Tue, 27 Jul 1999 04:52:39 -0700 (PDT) (envelope-from mpp@mpp.pro-ns.net) Received: (from mpp@localhost) by mpp.pro-ns.net (8.9.3/8.9.3) id GAA02583; Tue, 27 Jul 1999 06:51:58 -0500 (CDT) (envelope-from mpp) From: Mike Pritchard Message-Id: <199907271151.GAA02583@mpp.pro-ns.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907270348.UAA49943@apollo.backplane.com> from Matthew Dillon at "Jul 26, 1999 08:48:28 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Tue, 27 Jul 1999 06:51:58 -0500 (CDT) Cc: green@FreeBSD.org (Brian F. Feldman), jgreco@ns.sol.net (Joe Greco), hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL54 (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 may be some confusion here. I am advocating that we *allow* the > :> zeroing of counters at secure level 3. > : > :Which is what I am advocating against. > > Let me put it a different way: > > ipfw allows you to clear counters. It is a feature that already exists. > > However, it does not allow you to do it if you are sitting at secure > level 3. > > Why not? I can't think of any good reason why clearing the counters > should be disallowed when sitting at a higher secure level. The counters > are nothing more then statistics. Clearing statistics is not a security > threat. But it might be hiding a real security threat/attack or a real breakin. Say I've spent all night trying to hack into your machine and finally get in. If I can reset all of ipfw's counters back to zero, and this is something your security checking scripts are checking, you might not think that anyone has even been trying to break into your machine, much less made it into the machine. If I have some inside information, I could probably even get the counters back into the range where you might expect them to be at. Hopefully if this were to happen, you might see some other console/syslog messages or something else that catches your eye, but then again, maybe not. Just to help out people running at higher security levels, you could always implement something that lets you reset the values to some higher value that is easy to do computations from. E.g. ipfw --increment_counters=20000 Which would bump all of the counters up to the value of "20000", assuming they are all still less than that value. That way if you are trying to do some testing/debugging/counting after setting the counters, at least you have a nice round number to subtract from the current values. -- Mike Pritchard mpp@FreeBSD.ORG or mpp@mpp.pro-ns.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 7:23:57 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 2DA8914BEC; Tue, 27 Jul 1999 07:23:32 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id JAA90029; Tue, 27 Jul 1999 09:22:36 -0500 (CDT) From: Joe Greco Message-Id: <199907271422.JAA90029@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: from "Brian F. Feldman" at "Jul 26, 1999 11:12:37 pm" To: green@FreeBSD.org (Brian F. Feldman) Date: Tue, 27 Jul 1999 09:22:36 -0500 (CDT) Cc: dillon@apollo.backplane.com, jgreco@ns.sol.net, hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL43 (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 > On Mon, 26 Jul 1999, Matthew Dillon wrote: > > :Instead of zeroing it, how about raising the logging limit to (current + > > :whatever the limit was) > > : > > : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ > > : green@FreeBSD.org _ __ ___ | _ ) __| \ > > > > The way I see it either some piece of software is monitor the counters, > > in which case the sysad does not need to clear them and does not need to > > look at log messages, or the sysad is monitoring the stuff manually and > > using the log messages. In the one case the counters don't need to be > > cleared (and, indeed, should not be), in the other case the sysad may > > want to clear them due to the manual monitoring. > > > > What we are really discussing here is the use of ipfw's counters in an > > unsophisticated setup. The sophisticated setup is already handled. > > That doesn't mean we shouldn't allow people to have an unsophisticated setup, > just because a sophisticated one is available. It would be useful to have > a per-firewall-rule counter, decrement it on each match if logging and > set, and be able to reset to something higher. This doesn't work the way you say. If there was a single global VERBOSE_LIMIT counter, yes, it'd be trivial to monitor for it to max out and then raise the limit. However, with the current design, what will happen is ... let's say you have ten log rules. Your intruder spends a few days puttering and in the meantime gets your auto monitoring system to raise the limit to 100,000 in 100-increment steps, by beating on Rule #1. Now, all of a sudden, Rule #2's counter is still at 0 and the limit is at 100,000... do you see the potential for damage, or need I point out #3-9? What you describe would be fine if there was a single global VERBOSE_LIMIT, but in that event I'm not sure what difference there would be between doing this limit-raise thing and just resetting the counter. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 9:38: 3 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 62BB314DB7; Tue, 27 Jul 1999 09:37:57 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA54522; Tue, 27 Jul 1999 09:37:09 -0700 (PDT) (envelope-from dillon) Date: Tue, 27 Jul 1999 09:37:09 -0700 (PDT) From: Matthew Dillon Message-Id: <199907271637.JAA54522@apollo.backplane.com> To: Mike Pritchard Cc: green@FreeBSD.ORG (Brian F. Feldman), jgreco@ns.sol.net (Joe Greco), hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero References: <199907271151.GAA02583@mpp.pro-ns.net> Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :But it might be hiding a real security threat/attack or a real breakin. :Say I've spent all night trying to hack into your machine and finally get in. :If I can reset all of ipfw's counters back to zero, and this is :something your security checking scripts are checking, you might not :think that anyone has even been trying to break into your machine, much :less made it into the machine. If I have some inside information, :I could probably even get the counters back into the range where you :might expect them to be at. : :Hopefully if this were to happen, you might see some other console/syslog :messages or something else that catches your eye, but then again, :maybe not. : :Just to help out people running at higher security levels, you could :always implement something that lets you reset the values to some :... :Mike Pritchard I find this scenario highly unlikely. I can think of a thousand things. Well, a dozen anyway, that said hacker could do to the machine that are far more serious then clearing ipfw counters. And for that reason, I don't really consider it a realistic scenario. The hacker isn't going to give a damn about the ipfw counters. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 9:44: 9 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from sprint4.tmp1.allied.com (207-218-5-255.nas-1.SCF.primenet.com [207.218.5.255]) by hub.freebsd.org (Postfix) with ESMTP id CEE0E151E1 for ; Tue, 27 Jul 1999 09:44:04 -0700 (PDT) (envelope-from fontenot@primenet.com) Received: from sprint4.tmp1.allied.com (wpfonten@localhost [127.0.0.1]) by sprint4.tmp1.allied.com (8.9.3/8.9.3) with SMTP id JAA04614 for ; Tue, 27 Jul 1999 09:39:12 -0700 (MST) (envelope-from fontenot@primenet.com) From: Paul Fontenot To: freebsd-ipfw@freebsd.org Subject: Getting started Date: Tue, 27 Jul 1999 09:38:26 -0700 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <99072709391200.04540@sprint4.tmp1.allied.com> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is there a good freebsd guide to getting started on your own firewall? -Paul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 9:52:45 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id C5C2E1522F; Tue, 27 Jul 1999 09:52:33 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id KAA15209; Tue, 27 Jul 1999 10:52:23 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA25747; Tue, 27 Jul 1999 10:52:22 -0600 Date: Tue, 27 Jul 1999 10:52:22 -0600 Message-Id: <199907271652.KAA25747@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joe Greco Cc: nate@mt.sri.com (Nate Williams), dillon@apollo.backplane.com, hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <199907262136.QAA19479@aurora.sol.net> References: <199907262045.OAA21485@mt.sri.com> <199907262136.QAA19479@aurora.sol.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > You get *better* information on per-rule limits than on a global limit. > > No, you simply get a finer-grained ability to select. Which is almost always better. > > > If I'm an admin, I'm going to think "Well lets see, I want to store a > > > month of bad packets in it. > > > > If you're an admin on today's internet, you'd realize that there is *NO* > > way to get save a month worth of bad packets. Heck, at least once/week > > I can't even store a day's worth of bad packets (I assume when we say > > bad packets, we're talking about the > > If I'm an admin on today's internet (and I am), of course I realize that > I'm not going to save a month worth of all bad packets, but I _can_ choose > to hold onto a reasonable amount of logging information, which is what we > are discussing. Sure, but you can't call 'tossing 4/5 of the information that I receive in a totally arbritary manner' useful logging information. A global count would allow you to log information in a totally arbitrary manner. In that case, why have separate log rules? You may not ever get to see them if the limits are hit, so why not just one single rule to catch everything you want to log, since there's no guarantee that you'll see any logged information from the other rules. You might get something, but it's totally arbitrary and based upon known 'scripts' on what information is logged. Finer grained logging gives you *better* information, since it's more detailed. If you don't care about details, then why are you logging at all? > That is part of the _point_ of the IPFW_VERBOSE_LIMIT option... it > allows you to sample the beginning of each 5 minute period, and you > ought to be able to calculate the space required in a manner that > allows you to guarantee that you have sufficient space. I can't speak for the author, but as one of those involved in the discussion this wasn't even on the radar screen. The purpose of the option was to make DoS attacks less likely. It wasn't intended to provide you a good 'sampling' of attack packets on your system. Security is not effectively done by sampling. Sampling is too easy to thwart, and too often misses intrusions that are easily done by not doing sampling. :) And, because IPFW is so low-cost, there is very little reason to do sampling. Sampling is often done when 'real-time' monitoring is too expensive. What I'm hearing is that you want to change FreeBSD from doing 'real-time' monitoring to doing polling. The latter can be implemented from the former, but not vice-versa. We would be losing flexibility and usefulness by moving towards a 'polling' model. My advice to you is to quit 'polling' for packets (because as you've implied, you're not interested in the most of the information anyway), and use a *MUCH* smaller limit on your rules, and limit the number of rules you have, and you'll have almost the same result. > Now, if you're on an OC3c and you want to set IPFW_VERBOSE_LIMIT to 100000, > and you reset the counter every 5 minutes, you still _ought_ to be able to > determine that you require 2GB of disk space per day to keep those records. Great, but why even log data when you *plan* on throwing much of it away, in a totally arbitrary fashion. Why even bother? > (And if you're getting 100K rejectable packets every 5 minutes, something > is seriously wrong) Rejectable != log it. I reject alot of packets (most of them) and I don't care to log them. People do stupid things that aren't worthy of being logged, and there are alot of stupid people on the net doing things that aren't malicious that I don't care about. And, if you've got 100K 'logged' packets every 5 mins, then you better plan on having 2GB of disk-space/day if you care about saving them. Otherwise, if you don't have that much disk space, then don't reset every 5 minutes, since you can't keep the information. Either way you throw away information. With per-rule limits you have a much better idea on what kinds of information you are throwing away. (Fine-grained control). > > If you're logging that much information, then you're logging too much > > information. In any case, you've got information overload, so adding a > > global limit on the rules means you're losing as much (or more) > > information than you're logging, which is just as bad (or worse). > > No. You're not necessarily logging too much information. I do log a whole > bunch of shouldn't-happen scenarios, because if they do happen, it means > something is either horribly broken or somebody is doing something horribly > wrong. You might not see that happening since you're global rule was hit in the first 30 seconds by someone doing a POP3 scan of your entire network, followed by a breakin you missed. > I don't want an event such as an outbound source 10-net address to > happen... in theory it can't because I filter at my borders and use no > 10-net stuff internally. But I damn well want to know if it happens > ANYWAYS. You will have a very small chance of noticing it with a global limit. If you're truly concerned that you can generate 100K/sec of logging and want 5 minute resets (or whatever), then build your system with 18GB of disk and live with it. Otherwise, > > If you're worried about logging too much information, then don't reset > > your counters every 5 minutes. Besides, you're losing information if > > you're max'd out every 5 minutes anyway, so it really doesn't matter > > when you zero out your counters. > > You just argued my point for me, thank you. I _want_ to see the things that > I choose to log, and by definition once I pass IPFW_VERBOSE_LIMIT, then the > information is beyond the point of being useful. True, but the information you gather that you are losing is totally arbitrary with a global counter. With individual counters, you tend to lose information on similar attacks, and in a DoS attack the information is mostly redundant. > > > I don't know what you mean by "make the rules 'more verbose'" but what I > > > am advocating is not any change in what currently exists... I am talking > > > about limiting the number of entries possible in a manner that would seem > > > to be more consistent with the intent behind IPFW_VERBOSE_LIMIT. > > > > IPFW_VERBOSE_LIMIT is a per/rule limit. This is what is intended. Most > > attacks don't hit the entire system on every rule in order to do a DoS > > attack. Even so, each rule with eventually 'limit-out' and the system > > will no longer log packets. This is a 'bad thing' from a security > > standpoint, since at that point we are losing information. > > Okay, so what YOU really want is to not set up an IPFW_VERBOSE_LIMIT at all, > and that's perfectly valid as well. That's not what I said. You *must* have this to avoid DoS attacks. > > The idea behind IPFW_VERBOSE_LIMIT is to avoid DoS attacks, while still > > allowing *MAXIMUM* data collection when a DoS attack is not happening. > > > > It's not there to make your logfiles small. If you want small logfiles, > > turn of IPFW logging altogether. > > > > (I'm actually serious here.) > > Oh, that's a f'ing crock. What _I_ really want is to be able to GET the > god damn information when the system is in securemode 3 and the damn IPFW > has stopped logging due to the VERBOSE_LIMIT. You think I'm interested in > turning OFF IPFW logging? Yes, I think you are. You expect to lose information, and you don't care to know what kind of information you are losing. With per-rule counters, at least I know what kind of information I'm losing. > The stated rationale behind adding VERBOSE_LIMIT, when it was added, was to > reduce or eliminate the chance of a DoS attack. Now, the best way to > eliminate the chance of a DoS attack is _algorithmically_. Giving someone > a mechanism that allows them to determine the maximum resource commitment > for a given scenario eliminates the chance for that DoS attack. Giving > someone a mechanism that may use a variable quantity of resources is the > typical programming practice that leads to a resource starvation DoS. Let's see. 1) You know your IPFW rule limits 2) You know how many rules log 3) You know how often your counters are zero'd. Therefore, you can algorithmically determine how many resources are required (worst case) to not fill up your disks. No problem. You have everything you need to do the job. We haven't done anything different with a global counter *EXCEPT* make the kind of information you lose in a DoS attack totally arbitrary. And, in most DoS attacks, they tend to hit a single rule. You're still able to gather information on subsequent attacks that are unrelated to the first attack. A win-win situation. In any case, you aren't going to convince me that a global counter is better than a per-rule counter. No way, no how, so I'm going to drop the discussion. > What I absolutely need is a way to clear out the VERBOSE_LIMIT > counter. I've not argued for/against this ability at securelevel 3. I'm of two minds. There are valid arguments both ways, and without more feedback from others, I'm certainly not going to code up something or apply patches that I don't feel comfortable with. But, I'm interested in the results, since this is an issue that I face on a regular basis, hence my postings. Somehow, a discussion about zero-ing out firewall counters degenerated into a global vs. per-rule counter argument, and that's 'counter' to the original problem. :) :) > > One could argue that accounting numbers in a firewall shouldn't be > > trusted, but I won't argue that point since the firewall is often the > > most 'natural' place to stick network accounting software. > > If you can't trust something in the kernel, then you just can't trust > anything at all. It isn't the kernel that's zero'ing the counters. :) > > > Well, the 'right' thing is clear: pull the limit count out of the > > > accounting count. This solves both the problem of zeroing accounting > > > counters and potentially messing with other things, and also of letting > > > people do anything 'negative' in securelevel 3. > > > > Is it the 'right' thing to do? I think that someone messing with the > > 'logging' rule counts could be just as dangerous as someone messing with > > the accounting counts. > > It is no more dangerous Agreed. But it's 'just as dangerous', and letting people mess with the counters in securelevel == 3 *IS* the issue. Should it be allowed? Yes, it's nice to do. But, the point of high securelevel is to avoid *ANYTHING* (even useful things) that might compromise the integrity of the system. And, the IPFW counters constitute part of the integrity of the system. Is it part of the system that should be modifiable? I don't know, there are issues on both sides of the argument. Neither side is compelling enough (in my mind) to change the existing behavior. I, and somebody zeroing (the only thing they should > > Again, if you're paranoid enough to have securelevel 3, you've got to be > > paranoid enough to assume that someone *HAS* root access on your box, > > and is going to do anything nasty they could. > > Yes, but causing additional logging to happen is going to be something that > is likely to _attract_ my attention. If they've got root, they can also mess with your logfiles. > > > By pulling the limit count out into a separate entity, nothing > > > 'negative' can happen (because stopping the logging process is > > > definitely negative, and being able to restart it without messing with > > > other stuff is positive). > > > > I'm not sure this is an acceptable change either, but I'll leave that > > discussion to the networking folks. > > > > > Now that we are agreed that the limit count needs to be divorced from the > > > accounting count, we can debate whether it should be a per-rule or global > > > limit. > > > > Hold on to your horses, Hoss. I haven't agreed to that. Don't be > > putting words in my mouth. :) :) > > Well, then, how do you "fix" this problem? I don't know if it's a problem that should be fixed. The side-effects of the fix are potentially as bad as the existing problem. It's not a bug, it's a feature. :) :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 10: 7:52 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from the.oneinsane.net (the.oneinsane.net [207.113.133.228]) by hub.freebsd.org (Postfix) with ESMTP id 891EF14E10 for ; Tue, 27 Jul 1999 10:07:38 -0700 (PDT) (envelope-from insane@lunatic.oneinsane.net) Received: from lunatic.oneinsane.net (insane@lunatic.oneinsane.net [207.113.133.231]) by the.oneinsane.net (8.9.3/8.9.3) with ESMTP id KAA28305 for ; Tue, 27 Jul 1999 10:07:37 -0700 (PDT) Received: (from insane@localhost) by lunatic.oneinsane.net (8.9.3/8.9.3) id KAA28398 for freebsd-ipfw@freebsd.org; Tue, 27 Jul 1999 10:07:36 -0700 (PDT) (envelope-from insane) Date: Tue, 27 Jul 1999 10:07:36 -0700 From: "Ron 'The InSaNe One' Rosson" To: freebsd-ipfw@freebsd.org Subject: Re: Getting started Message-ID: <19990727100736.A28093@lunatic.oneinsane.net> Reply-To: Ron Rosson References: <99072709391200.04540@sprint4.tmp1.allied.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <99072709391200.04540@sprint4.tmp1.allied.com>; from Paul Fontenot on Tue, Jul 27, 1999 at 09:38:26AM -0700 X-Operating-System: FreeBSD lunatic.oneinsane.net 3.2-STABLE X-Opinion: What you read here is my IMHO X-Disclaimer: I am a firm believer in RTFM X-WWW: http://www.oneinsane.net X-PGP-KEY: http://www.oneinsane.net/~insane/insane-pgp5i.txt X-Uptime: 10:05AM up 5 days, 18:26, 2 users, load averages: 0.08, 0.03, 0.01 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 27 Jul 1999, Paul Fontenot was heard blurting out: > Is there a good freebsd guide to getting started on your own firewall? > > -Paul I would invest in one of the books that are mentione in the /etc/rc.firewall file. I have one of them and it helped tremendously. Plus you have the mailing list archive. There is a URL that shows some Firewall examples mentioned in the mailing list archives as well. -- ------------------------------------------------------------------- Ron Rosson ... and a UNIX user said ... The InSaNe One rm -rf * insane@oneinsane.net and all was null and void ------------------------------------------------------------------- If Barbie is so popular, why do you have to buy her friends? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 10:12:57 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id EEB3314DE1; Tue, 27 Jul 1999 10:12:48 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA15478; Tue, 27 Jul 1999 11:12:26 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA25861; Tue, 27 Jul 1999 11:12:25 -0600 Date: Tue, 27 Jul 1999 11:12:25 -0600 Message-Id: <199907271712.LAA25861@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matthew Dillon Cc: "Brian F. Feldman" , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <199907270307.UAA49737@apollo.backplane.com> References: <199907270307.UAA49737@apollo.backplane.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :Instead of zeroing it, how about raising the logging limit to (current + > :whatever the limit was) > : > : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ > : green@FreeBSD.org _ __ ___ | _ ) __| \ > > The way I see it either some piece of software is monitor the counters, > in which case the sysad does not need to clear them and does not need to > look at log messages, or the sysad is monitoring the stuff manually and > using the log messages. In the one case the counters don't need to be > cleared (and, indeed, should not be), in the other case the sysad may > want to clear them due to the manual monitoring. How do you figure? Currently, the kernel will quit 'logging' denied packets when the counter reaches a specific (compiled-in) number. Once that number is hit, you get 'hits', but no details as to what the signature of the hits are. The current 'signature' includes all of the IP information and such, which is invaluable (necessary?) for determing who's doing bad things (or not). This is in the kernel, and currently there is no way of modifying the counters in high securelevels. It doesn't matter if it's a human or a computer monitoring them, once the limit is reached alot of useful information is lost since the kernel no longer produces this information. # ipfw add 110 deny log tcp from any to any 110 via ed0 in Once the compiled in limit is reached, the kernel only says that we've got a hit, but it doesn't tell me who/when this happened. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 10:13:50 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id ADC7615069; Tue, 27 Jul 1999 10:13:41 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA15485; Tue, 27 Jul 1999 11:13:30 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA25874; Tue, 27 Jul 1999 11:13:29 -0600 Date: Tue, 27 Jul 1999 11:13:29 -0600 Message-Id: <199907271713.LAA25874@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matthew Dillon Cc: "Brian F. Feldman" , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <199907270316.UAA49808@apollo.backplane.com> References: <199907270316.UAA49808@apollo.backplane.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :That doesn't mean we shouldn't allow people to have an unsophisticated setup, > :just because a sophisticated one is available. It would be useful to have > :a per-firewall-rule counter, decrement it on each match if logging and > :set, and be able to reset to something higher. > : > : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ > > There may be some confusion here. I am advocating that we *allow* the > zeroing of counters at secure level 3. Sorry Matt, I missed that in my previous posting as well.... Ignore my previous followup. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 10:15:21 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 181E4152C5; Tue, 27 Jul 1999 10:15:16 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA15513; Tue, 27 Jul 1999 11:15:12 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA25892; Tue, 27 Jul 1999 11:15:11 -0600 Date: Tue, 27 Jul 1999 11:15:11 -0600 Message-Id: <199907271715.LAA25892@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: "Brian F. Feldman" , Matthew Dillon , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I like the ability at secure level 3 to only reset the counters forward.. > It fits in with such things as the "append only" flag. Then we'd have to implement per-rule counters that default to IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very different setup than what we currently have. (Another thing I just thought of is that this could cause DoS attacks on the system if a user compromised root and then set the limit to a very high number.) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 10:18:34 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 7729214E10; Tue, 27 Jul 1999 10:18:27 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA15551; Tue, 27 Jul 1999 11:18:03 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA25910; Tue, 27 Jul 1999 11:18:02 -0600 Date: Tue, 27 Jul 1999 11:18:02 -0600 Message-Id: <199907271718.LAA25910@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matthew Dillon Cc: "Brian F. Feldman" , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <199907270348.UAA49943@apollo.backplane.com> References: <199907270348.UAA49943@apollo.backplane.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ipfw allows you to clear counters. It is a feature that already exists. > > However, it does not allow you to do it if you are sitting at secure > level 3. > > Why not? I can't think of any good reason why clearing the counters > should be disallowed when sitting at a higher secure level. The counters > are nothing more then statistics. Clearing statistics is not a security > threat. I just thought of a bad thing. If you allowed the counters to be zero'd (or advanced) at securelevel == 3, then a 'malicious user' could write a cronjob to continually reset them and cause a DoS attack on the system (or in the case of advance, reset them to ridiculously high values), thus filling up the disk. However, one could argue that *IF* they have root, they could just as easily fill the disk with garbage and cause the same attack, ie; # dd if=/dev/zero of=/var/log/misc > The discussion should simply be about that. Not all this garbage > about adding new features. There's a feature that does not seem > to impact security, secure level disallows it, why? I'm not convinced there aren't other security implications from zero'ing (or advancing) the counters. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 10:25: 5 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 24E28151FC; Tue, 27 Jul 1999 10:24:58 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA54897; Tue, 27 Jul 1999 10:24:47 -0700 (PDT) (envelope-from dillon) Date: Tue, 27 Jul 1999 10:24:47 -0700 (PDT) From: Matthew Dillon Message-Id: <199907271724.KAA54897@apollo.backplane.com> To: Nate Williams Cc: "Brian F. Feldman" , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero References: <199907270348.UAA49943@apollo.backplane.com> <199907271718.LAA25910@mt.sri.com> Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I just thought of a bad thing. If you allowed the counters to be zero'd :(or advanced) at securelevel == 3, then a 'malicious user' could write a :cronjob to continually reset them and cause a DoS attack on the system :(or in the case of advance, reset them to ridiculously high values), :thus filling up the disk. : :However, one could argue that *IF* they have root, they could just as :easily fill the disk with garbage and cause the same attack, ie; : :# dd if=/dev/zero of=/var/log/misc The hacker w/ root would have to be a complete bozo to write a cron job or loop to clear the ipfw counters rather then do something else that really blows the machine away! It isn't a scenario that fills me with fear. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 10:34:16 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from WWW.GraphicExpress.Net (www.GraphicExpress.net [206.168.188.162]) by hub.freebsd.org (Postfix) with ESMTP id 6370A1522A for ; Tue, 27 Jul 1999 10:33:59 -0700 (PDT) (envelope-from staylor@graphicexpress.net) Received: from graphicexpress.net (INTRIGUE.eotek.com [204.133.131.183]) by WWW.GraphicExpress.Net (8.9.3/8.9.2) with ESMTP id LAA09590 for ; Tue, 27 Jul 1999 11:33:58 -0600 (MDT) Message-ID: <379DED83.70D4B4BE@graphicexpress.net> Date: Tue, 27 Jul 1999 11:33:55 -0600 From: Scott Taylor X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: reflexive access lists? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG One of the rules that I have in the access lists on my cisco routers that I wish I could setup of my freebsd box are reflexive access lists. I'd love to be able to allow packets that are replies to requests from my machine be automatically allowed without allowing such a blanket permission as allowing all tcp packets with the established flag set. Reflexive lists allow me to setup harsh firewall rules yet give processes on my machine transparent access to the outside world. Here's a page by cisco describing setting up a reflexive list: http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/secur_c/scprt3/screflex.htm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 10:35:12 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from gemini.bnc.net (gemini.bnc.net [195.247.233.33]) by hub.freebsd.org (Postfix) with ESMTP id 8DBC7152E3; Tue, 27 Jul 1999 10:35:01 -0700 (PDT) (envelope-from ap@bnc.net) Received: (from ap@localhost) by gemini.bnc.net (8.9.3/8.9.3) id TAA74620; Tue, 27 Jul 1999 19:33:49 +0200 (CEST) (envelope-from ap) Date: Tue, 27 Jul 1999 19:33:49 +0200 From: Achim Patzner To: Nate Williams Cc: Matthew Dillon , "Brian F. Feldman" , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero Message-ID: <19990727193349.K58970@bnc.net> References: <199907270307.UAA49737@apollo.backplane.com> <199907271712.LAA25861@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907271712.LAA25861@mt.sri.com>; from Nate Williams on Tue, Jul 27, 1999 at 11:12:25AM -0600 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 27, 1999 at 11:12:25AM -0600, Nate Williams wrote: > How do you figure? Currently, the kernel will quit 'logging' denied > packets when the counter reaches a specific (compiled-in) number. ^^^^^^^^^^^^^ Then what is net.inet.ip.fw.verbose_limit: 0 made for and why does it help changing it? 8-) It might also be nicer to give it its own facility for syslog... Achim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 10:37:31 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id B171215235; Tue, 27 Jul 1999 10:37:10 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA15796; Tue, 27 Jul 1999 11:35:22 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA26067; Tue, 27 Jul 1999 11:35:20 -0600 Date: Tue, 27 Jul 1999 11:35:20 -0600 Message-Id: <199907271735.LAA26067@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Achim Patzner Cc: Nate Williams , Matthew Dillon , "Brian F. Feldman" , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <19990727193349.K58970@bnc.net> References: <199907270307.UAA49737@apollo.backplane.com> <199907271712.LAA25861@mt.sri.com> <19990727193349.K58970@bnc.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > How do you figure? Currently, the kernel will quit 'logging' denied > > packets when the counter reaches a specific (compiled-in) number. > ^^^^^^^^^^^^^ > Then what is > > net.inet.ip.fw.verbose_limit: 0 Well I'll be. You learn something new everyday. :) > made for and why does it help changing it? 8-) Ahh. However, unfortunately, this 'limit' changes *all* of the per-rule counters, when in fact you may only want to change a single counter. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 10:44:40 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from gemini.bnc.net (gemini.bnc.net [195.247.233.33]) by hub.freebsd.org (Postfix) with ESMTP id 99BFA152B7; Tue, 27 Jul 1999 10:44:34 -0700 (PDT) (envelope-from ap@bnc.net) Received: (from ap@localhost) by gemini.bnc.net (8.9.3/8.9.3) id TAA74659; Tue, 27 Jul 1999 19:42:45 +0200 (CEST) (envelope-from ap) Date: Tue, 27 Jul 1999 19:42:45 +0200 From: Achim Patzner To: Nate Williams Cc: Julian Elischer , "Brian F. Feldman" , Matthew Dillon , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero Message-ID: <19990727194245.L58970@bnc.net> References: <199907271715.LAA25892@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907271715.LAA25892@mt.sri.com>; from Nate Williams on Tue, Jul 27, 1999 at 11:15:11AM -0600 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 27, 1999 at 11:15:11AM -0600, Nate Williams wrote: > Then we'd have to implement per-rule counters that default to > IPFW_VERBOSE_LIMIT but that could be changed to anything. *falling on my knees* If you're going to do that what would it cost me (in chocolate bars or sushi) to get you to implement a second set of counters that will be filled by zeroing the first set (so I was able to read out counters and reset them without losing accounting information)? Or at least make zeroing printing out the contents before clearing them? Oh and while we're at it.... *runs away and tries hiding* > (Another thing I just thought of is that this could cause DoS attacks on > the system if a user compromised root and then set the limit to a very > high number.) If you have someone going berzerk as "root" on a firewall you're definitely going to have a completely different set of headaches. Why should someone start DoS attacks after capturing a firewall? It's like painting the fingernails before amputating the hand. Achim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 10:54: 9 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 6EA421532F; Tue, 27 Jul 1999 10:54:02 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA16057; Tue, 27 Jul 1999 11:53:42 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA26248; Tue, 27 Jul 1999 11:53:41 -0600 Date: Tue, 27 Jul 1999 11:53:41 -0600 Message-Id: <199907271753.LAA26248@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Achim Patzner Cc: Nate Williams , Julian Elischer , "Brian F. Feldman" , Matthew Dillon , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <19990727194245.L58970@bnc.net> References: <199907271715.LAA25892@mt.sri.com> <19990727194245.L58970@bnc.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > (Another thing I just thought of is that this could cause DoS attacks on > > the system if a user compromised root and then set the limit to a very > > high number.) > > If you have someone going berzerk as "root" on a firewall you're definitely > going to have a completely different set of headaches. Why should someone > start DoS attacks after capturing a firewall? It's like painting the > fingernails before amputating the hand. So it was a bad example. If I had enough brain cells to boil a cup of water for my soup I'd be able to come up with more 'viable' issues where modifying the counters is a bad thing. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 11:58:30 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 5B52C14BFF; Tue, 27 Jul 1999 11:58:15 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id NAA09504; Tue, 27 Jul 1999 13:56:55 -0500 (CDT) From: Joe Greco Message-Id: <199907271856.NAA09504@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271652.KAA25747@mt.sri.com> from Nate Williams at "Jul 27, 1999 10:52:22 am" To: nate@mt.sri.com (Nate Williams) Date: Tue, 27 Jul 1999 13:56:55 -0500 (CDT) Cc: hackers@freebsd.org, freebsd-ipfw@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (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 > > > You get *better* information on per-rule limits than on a global limit. > > > > No, you simply get a finer-grained ability to select. > > Which is almost always better. > > > > > If I'm an admin, I'm going to think "Well lets see, I want to store a > > > > month of bad packets in it. > > > > > > If you're an admin on today's internet, you'd realize that there is *NO* > > > way to get save a month worth of bad packets. Heck, at least once/week > > > I can't even store a day's worth of bad packets (I assume when we say > > > bad packets, we're talking about the > > > > If I'm an admin on today's internet (and I am), of course I realize that > > I'm not going to save a month worth of all bad packets, but I _can_ choose > > to hold onto a reasonable amount of logging information, which is what we > > are discussing. > > Sure, but you can't call 'tossing 4/5 of the information that I receive > in a totally arbritary manner' useful logging information. A global > count would allow you to log information in a totally arbitrary manner. No, it would give me complete control - up to the point where I've decided that further information is not useful. > In that case, why have separate log rules? You may not ever get to see > them if the limits are hit, so why not just one single rule to catch > everything you want to log, since there's no guarantee that you'll see > any logged information from the other rules. There's no guarantee either way. As long as you specify some limit at all, you risk losing data. Hell, you risk losing data if syslogd can't keep up with the kernel message buffer, or if your disk fills... > You might get something, but it's totally arbitrary and based upon known > 'scripts' on what information is logged. > > Finer grained logging gives you *better* information, since it's more > detailed. If you don't care about details, then why are you logging at > all? Because I want to know when Bad Things Happen. > > That is part of the _point_ of the IPFW_VERBOSE_LIMIT option... it > > allows you to sample the beginning of each 5 minute period, and you > > ought to be able to calculate the space required in a manner that > > allows you to guarantee that you have sufficient space. > > I can't speak for the author, but as one of those involved in the > discussion this wasn't even on the radar screen. The purpose of the > option was to make DoS attacks less likely. It wasn't intended to > provide you a good 'sampling' of attack packets on your system. > > Security is not effectively done by sampling. Sampling is too easy to > thwart, and too often misses intrusions that are easily done by not > doing sampling. :) > > And, because IPFW is so low-cost, there is very little reason to do > sampling. Sampling is often done when 'real-time' monitoring is too > expensive. So.... what are you saying? I'm saying that you can set the limit as high as you feel necessary to be comfortable that you are getting sufficient data from the filter. In the event that you exceed the limit, I'm also saying that further data becomes largely irrelevant and/or a liability, and that it should be dropped. I'm not saying I just want to "sample" the first packet I get every five minutes. However, if I'm getting more than a thousand, the additional detail is useless. > What I'm hearing is that you want to change FreeBSD from doing > 'real-time' monitoring to doing polling. The latter can be implemented > from the former, but not vice-versa. We would be losing flexibility and > usefulness by moving towards a 'polling' model. No, nobody except you used the word "polling". You can continue to monitor in realtime. I'm merely looking for a way to restart monitoring after the system has clamped down (VERBOSE_LIMIT) on excessive logging, and I'm also questioning if there is a better way to implement the VERBOSE_LIMIT. > My advice to you is to quit 'polling' for packets (because as you've > implied, you're not interested in the most of the information anyway), Bull f****ng s#!+ I'm not interested in the information! However, I'm probably not interested in (or going to look at) more than 1000 entries per five minute period. > and use a *MUCH* smaller limit on your rules, and limit the number of > rules you have, and you'll have almost the same result. I am _not_ about to reduce the number of rules I feel are necessary to have. They are all there for a good reason. Paranoia. :-) > > Now, if you're on an OC3c and you want to set IPFW_VERBOSE_LIMIT to 100000, > > and you reset the counter every 5 minutes, you still _ought_ to be able to > > determine that you require 2GB of disk space per day to keep those records. > > Great, but why even log data when you *plan* on throwing much of it > away, in a totally arbitrary fashion. Why even bother? So you argue for getting rid of the IPFW_VERBOSE_LIMIT function, then? Well then fine, just be quiet, don't define it in the first place, and abstain from participating in this discussion. Otherwise, you are clearly *planning* to throw away data at some point, so your argument becomes internally inconsistent! > > (And if you're getting 100K rejectable packets every 5 minutes, something > > is seriously wrong) > > Rejectable != log it. I reject alot of packets (most of them) and I > don't care to log them. People do stupid things that aren't worthy of > being logged, and there are alot of stupid people on the net doing > things that aren't malicious that I don't care about. And I do. > And, if you've got 100K 'logged' packets every 5 mins, then you better > plan on having 2GB of disk-space/day if you care about saving them. > > Otherwise, if you don't have that much disk space, then don't reset > every 5 minutes, since you can't keep the information. Either way you > throw away information. With per-rule limits you have a much better > idea on what kinds of information you are throwing away. (Fine-grained > control). You're now arguing that it is OK to throw away information. Talk about fighting whatever side is convenient at the time. > > > If you're logging that much information, then you're logging too much > > > information. In any case, you've got information overload, so adding a > > > global limit on the rules means you're losing as much (or more) > > > information than you're logging, which is just as bad (or worse). > > > > No. You're not necessarily logging too much information. I do log a whole > > bunch of shouldn't-happen scenarios, because if they do happen, it means > > something is either horribly broken or somebody is doing something horribly > > wrong. > > You might not see that happening since you're global rule was hit in the > first 30 seconds by someone doing a POP3 scan of your entire network, > followed by a breakin you missed. > > > I don't want an event such as an outbound source 10-net address to > > happen... in theory it can't because I filter at my borders and use no > > 10-net stuff internally. But I damn well want to know if it happens > > ANYWAYS. > > You will have a very small chance of noticing it with a global limit. That's odd. I see them when they happen. Maybe it is because I'm busy making sure that this kind of stuff doesn't propagate that far into my network in the first place. > If you're truly concerned that you can generate 100K/sec of logging and > want 5 minute resets (or whatever), then build your system with 18GB of > disk and live with it. Otherwise, > > > > If you're worried about logging too much information, then don't reset > > > your counters every 5 minutes. Besides, you're losing information if > > > you're max'd out every 5 minutes anyway, so it really doesn't matter > > > when you zero out your counters. > > > > You just argued my point for me, thank you. I _want_ to see the things that > > I choose to log, and by definition once I pass IPFW_VERBOSE_LIMIT, then the > > information is beyond the point of being useful. > > True, but the information you gather that you are losing is totally > arbitrary with a global counter. With individual counters, you tend to > lose information on similar attacks, and in a DoS attack the information > is mostly redundant. Okay, so again you are arguing to lose data. > > > > I don't know what you mean by "make the rules 'more verbose'" but what I > > > > am advocating is not any change in what currently exists... I am talking > > > > about limiting the number of entries possible in a manner that would seem > > > > to be more consistent with the intent behind IPFW_VERBOSE_LIMIT. > > > > > > IPFW_VERBOSE_LIMIT is a per/rule limit. This is what is intended. Most > > > attacks don't hit the entire system on every rule in order to do a DoS > > > attack. Even so, each rule with eventually 'limit-out' and the system > > > will no longer log packets. This is a 'bad thing' from a security > > > standpoint, since at that point we are losing information. > > > > Okay, so what YOU really want is to not set up an IPFW_VERBOSE_LIMIT at all, > > and that's perfectly valid as well. > > That's not what I said. You *must* have this to avoid DoS attacks. It _is_ what you said above. > > > The idea behind IPFW_VERBOSE_LIMIT is to avoid DoS attacks, while still > > > allowing *MAXIMUM* data collection when a DoS attack is not happening. > > > > > > It's not there to make your logfiles small. If you want small logfiles, > > > turn of IPFW logging altogether. > > > > > > (I'm actually serious here.) > > > > Oh, that's a f'ing crock. What _I_ really want is to be able to GET the > > god damn information when the system is in securemode 3 and the damn IPFW > > has stopped logging due to the VERBOSE_LIMIT. You think I'm interested in > > turning OFF IPFW logging? > > Yes, I think you are. You expect to lose information, and you don't > care to know what kind of information you are losing. With per-rule > counters, at least I know what kind of information I'm losing. > > > The stated rationale behind adding VERBOSE_LIMIT, when it was added, was to > > reduce or eliminate the chance of a DoS attack. Now, the best way to > > eliminate the chance of a DoS attack is _algorithmically_. Giving someone > > a mechanism that allows them to determine the maximum resource commitment > > for a given scenario eliminates the chance for that DoS attack. Giving > > someone a mechanism that may use a variable quantity of resources is the > > typical programming practice that leads to a resource starvation DoS. > > Let's see. > > 1) You know your IPFW rule limits > 2) You know how many rules log > 3) You know how often your counters are zero'd. > > Therefore, you can algorithmically determine how many resources are > required (worst case) to not fill up your disks. > > No problem. You have everything you need to do the job. We haven't > done anything different with a global counter *EXCEPT* make the kind of > information you lose in a DoS attack totally arbitrary. > > And, in most DoS attacks, they tend to hit a single rule. You're still > able to gather information on subsequent attacks that are unrelated to > the first attack. > > A win-win situation. > > In any case, you aren't going to convince me that a global counter is > better than a per-rule counter. No way, no how, so I'm going to drop > the discussion. Fine. > > What I absolutely need is a way to clear out the VERBOSE_LIMIT > > counter. > > I've not argued for/against this ability at securelevel 3. I'm of two > minds. There are valid arguments both ways, and without more feedback > from others, I'm certainly not going to code up something or apply > patches that I don't feel comfortable with. > > But, I'm interested in the results, since this is an issue that I face > on a regular basis, hence my postings. > > Somehow, a discussion about zero-ing out firewall counters degenerated > into a global vs. per-rule counter argument, and that's 'counter' to the > original problem. :) :) Yes. > > > One could argue that accounting numbers in a firewall shouldn't be > > > trusted, but I won't argue that point since the firewall is often the > > > most 'natural' place to stick network accounting software. > > > > If you can't trust something in the kernel, then you just can't trust > > anything at all. > > It isn't the kernel that's zero'ing the counters. :) Accounting numbers in a kernel firewall _should_ be trustable, and on that basis, one can clearly make an argument for separating the logging count from the accounting count - which should never be zero'ed, at least in securemode. I'm not saying your desire for per-rule counters is invalid, I'm just not of that same mindset. But it does seem clear that it would be useful to have a mechanism to restart the logging after an IPFW_VERBOSE_LIMIT throttle. > > > > Well, the 'right' thing is clear: pull the limit count out of the > > > > accounting count. This solves both the problem of zeroing accounting > > > > counters and potentially messing with other things, and also of letting > > > > people do anything 'negative' in securelevel 3. > > > > > > Is it the 'right' thing to do? I think that someone messing with the > > > 'logging' rule counts could be just as dangerous as someone messing with > > > the accounting counts. > > > > It is no more dangerous > > Agreed. But it's 'just as dangerous', and letting people mess with the > counters in securelevel == 3 *IS* the issue. Should it be allowed? This counter's only function would be to turn off logging after a limit was reached. Therefore, the question of resetting a counter is not the issue... it needs to be "would turning on logging after the kernel stopped it be an issue". I feel the answer is no. > Yes, it's nice to do. But, the point of high securelevel is to avoid > *ANYTHING* (even useful things) that might compromise the integrity of > the system. And, the IPFW counters constitute part of the integrity of > the system. Is it part of the system that should be modifiable? I > don't know, there are issues on both sides of the argument. Neither > side is compelling enough (in my mind) to change the existing behavior. > > I, and somebody zeroing (the only thing they should > > > > Again, if you're paranoid enough to have securelevel 3, you've got to be > > > paranoid enough to assume that someone *HAS* root access on your box, > > > and is going to do anything nasty they could. > > > > Yes, but causing additional logging to happen is going to be something that > > is likely to _attract_ my attention. > > If they've got root, they can also mess with your logfiles. > > > > > By pulling the limit count out into a separate entity, nothing > > > > 'negative' can happen (because stopping the logging process is > > > > definitely negative, and being able to restart it without messing with > > > > other stuff is positive). > > > > > > I'm not sure this is an acceptable change either, but I'll leave that > > > discussion to the networking folks. > > > > > > > Now that we are agreed that the limit count needs to be divorced from the > > > > accounting count, we can debate whether it should be a per-rule or global > > > > limit. > > > > > > Hold on to your horses, Hoss. I haven't agreed to that. Don't be > > > putting words in my mouth. :) :) > > > > Well, then, how do you "fix" this problem? > > I don't know if it's a problem that should be fixed. The side-effects > of the fix are potentially as bad as the existing problem. No, because the fix (putting in a separate logging counter) would not allow the accounting counters to be tampered with. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 11:59:37 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 9B2EC14BEE; Tue, 27 Jul 1999 11:59:26 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id NAA09676; Tue, 27 Jul 1999 13:59:16 -0500 (CDT) From: Joe Greco Message-Id: <199907271859.NAA09676@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271715.LAA25892@mt.sri.com> from Nate Williams at "Jul 27, 1999 11:15:11 am" To: nate@mt.sri.com (Nate Williams) Date: Tue, 27 Jul 1999 13:59:16 -0500 (CDT) Cc: julian@whistle.com, green@FreeBSD.ORG, dillon@apollo.backplane.com, jgreco@ns.sol.net, hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (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 > > I like the ability at secure level 3 to only reset the counters forward.. > > It fits in with such things as the "append only" flag. > > Then we'd have to implement per-rule counters that default to > IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very > different setup than what we currently have. > > (Another thing I just thought of is that this could cause DoS attacks on > the system if a user compromised root and then set the limit to a very > high number.) This is already possible via sysctl, the VERBOSE_LIMIT variable may be altered. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 12: 4:44 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 83A771535E; Tue, 27 Jul 1999 12:04:27 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id OAA09915; Tue, 27 Jul 1999 14:02:19 -0500 (CDT) From: Joe Greco Message-Id: <199907271902.OAA09915@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271735.LAA26067@mt.sri.com> from Nate Williams at "Jul 27, 1999 11:35:20 am" To: nate@mt.sri.com (Nate Williams) Date: Tue, 27 Jul 1999 14:02:19 -0500 (CDT) Cc: ap@bnc.net, nate@mt.sri.com, dillon@apollo.backplane.com, green@FreeBSD.ORG, jgreco@ns.sol.net, hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (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 > > > How do you figure? Currently, the kernel will quit 'logging' denied > > > packets when the counter reaches a specific (compiled-in) number. > > ^^^^^^^^^^^^^ > > Then what is > > > > net.inet.ip.fw.verbose_limit: 0 > > Well I'll be. You learn something new everyday. :) > > > made for and why does it help changing it? 8-) > > Ahh. However, unfortunately, this 'limit' changes *all* of the per-rule > counters, when in fact you may only want to change a single counter. The _problem_ with this (and it is FINE for doing interactive work on the system as far as I am concerned) is that in a production environment with machines with 800 day uptimes and securelevel 3, once you pass the VERBOSE_LIMIT, you _can_ disable VERBOSE_LIMIT by setting this to 0, but you then become vulnerable to the DoS attacks we have all been arguing about. In other words, it simply disables VERBOSE_LIMIT. Useful, as I said, if you have a low VERBOSE_LIMIT and you are getting some attack that you want to monitor firsthand in more detail... ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 12:17: 1 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 44C5B1522A; Tue, 27 Jul 1999 12:16:49 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id NAA17154; Tue, 27 Jul 1999 13:15:12 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA26782; Tue, 27 Jul 1999 13:15:11 -0600 Date: Tue, 27 Jul 1999 13:15:11 -0600 Message-Id: <199907271915.NAA26782@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joe Greco Cc: nate@mt.sri.com (Nate Williams), hackers@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271856.NAA09504@aurora.sol.net> References: <199907271652.KAA25747@mt.sri.com> <199907271856.NAA09504@aurora.sol.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > One could argue that accounting numbers in a firewall shouldn't be > > > > trusted, but I won't argue that point since the firewall is often the > > > > most 'natural' place to stick network accounting software. > > > > > > If you can't trust something in the kernel, then you just can't trust > > > anything at all. > > > > It isn't the kernel that's zero'ing the counters. :) > > Accounting numbers in a kernel firewall _should_ be trustable, and on that > basis, one can clearly make an argument for separating the logging count > from the accounting count - which should never be zero'ed, at least in > securemode. One could argue that 'logging counters' in a firewall _should_ be trustable as well. You've argued against it, but I'm not convinced that your opinion (or mine) is enough to consider it a 'bug'. > I'm not saying your desire for per-rule counters is invalid, I'm just not > of that same mindset. But it does seem clear that it would be useful to > have a mechanism to restart the logging after an IPFW_VERBOSE_LIMIT > throttle. It would be useful. But, is it's usefulness more important than being able to rely on 'logging counters' being valid? (You argue no, but I'm not convinced...) Again, it's not a fix, it's a feature. Not being able to mess with counters (logging or otherwise) is a feature. It may be a feature that you can do without, but that decision is not to be made lightly. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 12:18:54 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 8D9BC1527A; Tue, 27 Jul 1999 12:18:44 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id NAA17187; Tue, 27 Jul 1999 13:17:05 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA26828; Tue, 27 Jul 1999 13:17:05 -0600 Date: Tue, 27 Jul 1999 13:17:05 -0600 Message-Id: <199907271917.NAA26828@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joe Greco Cc: nate@mt.sri.com (Nate Williams), julian@whistle.com, green@FreeBSD.ORG, dillon@apollo.backplane.com, hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271859.NAA09676@aurora.sol.net> References: <199907271715.LAA25892@mt.sri.com> <199907271859.NAA09676@aurora.sol.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > I like the ability at secure level 3 to only reset the counters forward.. > > > It fits in with such things as the "append only" flag. > > > > Then we'd have to implement per-rule counters that default to > > IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very > > different setup than what we currently have. > > > > (Another thing I just thought of is that this could cause DoS attacks on > > the system if a user compromised root and then set the limit to a very > > high number.) > > This is already possible via sysctl, the VERBOSE_LIMIT variable may be > altered. Can this be altered in securelevel==3? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 12:49:47 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 8225F151BF; Tue, 27 Jul 1999 12:49:36 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id OAA13262; Tue, 27 Jul 1999 14:49:12 -0500 (CDT) From: Joe Greco Message-Id: <199907271949.OAA13262@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271915.NAA26782@mt.sri.com> from Nate Williams at "Jul 27, 1999 1:15:11 pm" To: nate@mt.sri.com (Nate Williams) Date: Tue, 27 Jul 1999 14:49:12 -0500 (CDT) Cc: jgreco@ns.sol.net, nate@mt.sri.com, hackers@freebsd.org, freebsd-ipfw@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (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 > > > > > One could argue that accounting numbers in a firewall shouldn't be > > > > > trusted, but I won't argue that point since the firewall is often the > > > > > most 'natural' place to stick network accounting software. > > > > > > > > If you can't trust something in the kernel, then you just can't trust > > > > anything at all. > > > > > > It isn't the kernel that's zero'ing the counters. :) > > > > Accounting numbers in a kernel firewall _should_ be trustable, and on that > > basis, one can clearly make an argument for separating the logging count > > from the accounting count - which should never be zero'ed, at least in > > securemode. > > One could argue that 'logging counters' in a firewall _should_ be > trustable as well. You've argued against it, but I'm not convinced that > your opinion (or mine) is enough to consider it a 'bug'. > > > I'm not saying your desire for per-rule counters is invalid, I'm just not > > of that same mindset. But it does seem clear that it would be useful to > > have a mechanism to restart the logging after an IPFW_VERBOSE_LIMIT > > throttle. > > It would be useful. But, is it's usefulness more important than being > able to rely on 'logging counters' being valid? (You argue no, but I'm > not convinced...) > > Again, it's not a fix, it's a feature. Not being able to mess with > counters (logging or otherwise) is a feature. It may be a feature that > you can do without, but that decision is not to be made lightly. I'm _saying_ to create a completely separate counter which has nothing to do with accounting. The counter which you "trust" for any purposes can be the accounting counter, which nobody can mess with in securemode. The logging counter is merely to allow VERBOSE_LIMIT whether or not the logging throttle should be engaged, and therefore you can EITHER: 1) Set a global VERBOSE_LIMIT mechanism and: a) allow your logging counter to be reset, or b) allow your limit to be raised to re-enable logging 2) Set a rule-oriented VERBOSE_LIMIT mechanism and allow each rule's logging counter to be reset. So, what's your vote? (I'm wondering if maybe we can do a combined 1a and 2 of some sort) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 12:51:35 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 7A0A615392; Tue, 27 Jul 1999 12:51:19 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id NAA17620; Tue, 27 Jul 1999 13:51:12 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA27049; Tue, 27 Jul 1999 13:51:11 -0600 Date: Tue, 27 Jul 1999 13:51:11 -0600 Message-Id: <199907271951.NAA27049@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joe Greco Cc: nate@mt.sri.com (Nate Williams), hackers@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271949.OAA13262@aurora.sol.net> References: <199907271915.NAA26782@mt.sri.com> <199907271949.OAA13262@aurora.sol.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Again, it's not a fix, it's a feature. Not being able to mess with > > counters (logging or otherwise) is a feature. It may be a feature that ^^^^^^^^^^^^^^^^^^^^ > > you can do without, but that decision is not to be made lightly. > > I'm _saying_ to create a completely separate counter which has nothing to > do with accounting. See above. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 12:52:10 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 4D1E614DD6; Tue, 27 Jul 1999 12:52:00 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id OAA13451; Tue, 27 Jul 1999 14:51:34 -0500 (CDT) From: Joe Greco Message-Id: <199907271951.OAA13451@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271917.NAA26828@mt.sri.com> from Nate Williams at "Jul 27, 1999 1:17: 5 pm" To: nate@mt.sri.com (Nate Williams) Date: Tue, 27 Jul 1999 14:51:34 -0500 (CDT) Cc: jgreco@ns.sol.net, nate@mt.sri.com, julian@whistle.com, green@FreeBSD.ORG, dillon@apollo.backplane.com, hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (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 > > > > I like the ability at secure level 3 to only reset the counters forward.. > > > > It fits in with such things as the "append only" flag. > > > > > > Then we'd have to implement per-rule counters that default to > > > IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very > > > different setup than what we currently have. > > > > > > (Another thing I just thought of is that this could cause DoS attacks on > > > the system if a user compromised root and then set the limit to a very > > > high number.) > > > > This is already possible via sysctl, the VERBOSE_LIMIT variable may be > > altered. > > Can this be altered in securelevel==3? # sysctl -a|grep secur kern.securelevel: 3 # sysctl -a|grep verbo net.inet.ip.fw.verbose: 1 net.inet.ip.fw.verbose_limit: 0 # sysctl -w net.inet.ip.fw.verbose_limit=999 net.inet.ip.fw.verbose_limit: 0 -> 999 "Any more questions?" :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 12:54:53 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 8E8A314EF4 for ; Tue, 27 Jul 1999 12:54:42 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id NAA17660; Tue, 27 Jul 1999 13:53:40 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA27097; Tue, 27 Jul 1999 13:53:39 -0600 Date: Tue, 27 Jul 1999 13:53:39 -0600 Message-Id: <199907271953.NAA27097@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joe Greco Cc: nate@mt.sri.com (Nate Williams), freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271951.OAA13451@aurora.sol.net> References: <199907271917.NAA26828@mt.sri.com> <199907271951.OAA13451@aurora.sol.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ Can IPFW's verbose limit be altered in securelevel 3 ] > # sysctl -a|grep secur > kern.securelevel: 3 > # sysctl -a|grep verbo > net.inet.ip.fw.verbose: 1 > net.inet.ip.fw.verbose_limit: 0 > # sysctl -w net.inet.ip.fw.verbose_limit=999 > net.inet.ip.fw.verbose_limit: 0 -> 999 > > "Any more questions?" :-) That looks like a bug to me, or at least an inconsistency with the firewall counters. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 12:56:33 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 80E481544F; Tue, 27 Jul 1999 12:56:24 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id OAA13811; Tue, 27 Jul 1999 14:56:18 -0500 (CDT) From: Joe Greco Message-Id: <199907271956.OAA13811@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271951.NAA27049@mt.sri.com> from Nate Williams at "Jul 27, 1999 1:51:11 pm" To: nate@mt.sri.com (Nate Williams) Date: Tue, 27 Jul 1999 14:56:17 -0500 (CDT) Cc: jgreco@ns.sol.net, nate@mt.sri.com, hackers@freebsd.org, freebsd-ipfw@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (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 > > > Again, it's not a fix, it's a feature. Not being able to mess with > > > counters (logging or otherwise) is a feature. It may be a feature that > ^^^^^^^^^^^^^^^^^^^^ > > > you can do without, but that decision is not to be made lightly. > > > > I'm _saying_ to create a completely separate counter which has nothing to > > do with accounting. > > See above. I did see above. If the sole purpose of a counter is to turn _off_ a feature to prevent DoS attacks, and it is clearly desirable that the admin (or a representative entity such as a monitoring system) would want to be able to re-enable the logging under those same terms at some admin-specified interval, how exactly would you choose to implement this? Please, be specific. If zeroing a counter whose sole purpose in life is to control logging output presents a problem for you, perhaps some other alternative is possible. I'm not quite sure what it would be. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 13: 0:15 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 137BA15489; Tue, 27 Jul 1999 13:00:01 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id NAA17738; Tue, 27 Jul 1999 13:59:59 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA27155; Tue, 27 Jul 1999 13:59:58 -0600 Date: Tue, 27 Jul 1999 13:59:58 -0600 Message-Id: <199907271959.NAA27155@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joe Greco Cc: nate@mt.sri.com (Nate Williams), hackers@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271956.OAA13811@aurora.sol.net> References: <199907271951.NAA27049@mt.sri.com> <199907271956.OAA13811@aurora.sol.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > Again, it's not a fix, it's a feature. Not being able to mess with > > > > counters (logging or otherwise) is a feature. It may be a feature that > > ^^^^^^^^^^^^^^^^^^^^ > > > > you can do without, but that decision is not to be made lightly. > > > > > > I'm _saying_ to create a completely separate counter which has nothing to > > > do with accounting. > > > > See above. > > I did see above. If the sole purpose of a counter is to turn _off_ a > feature to prevent DoS attacks, and it is clearly desirable that the > admin (or a representative entity such as a monitoring system) would > want to be able to re-enable the logging under those same terms at some > admin-specified interval, how exactly would you choose to implement this? What was originally intended and what it's used for now are two different things. I'd like to see people other than you, I, and Matt discussing this. Other people who use this feature of IPFW that have an opinion one way or the other should speak up. A group of two very opinionated people doesn't make a consensus, or necessarily the 'right' decision. :) :) :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 13: 5:45 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 4FF891522C; Tue, 27 Jul 1999 13:05:36 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id PAA14464; Tue, 27 Jul 1999 15:05:11 -0500 (CDT) From: Joe Greco Message-Id: <199907272005.PAA14464@aurora.sol.net> Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271959.NAA27155@mt.sri.com> from Nate Williams at "Jul 27, 1999 1:59:58 pm" To: nate@mt.sri.com (Nate Williams) Date: Tue, 27 Jul 1999 15:05:11 -0500 (CDT) Cc: jgreco@ns.sol.net, nate@mt.sri.com, hackers@freebsd.org, freebsd-ipfw@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (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 > > > > > Again, it's not a fix, it's a feature. Not being able to mess with > > > > > counters (logging or otherwise) is a feature. It may be a feature that > > > ^^^^^^^^^^^^^^^^^^^^ > > > > > you can do without, but that decision is not to be made lightly. > > > > > > > > I'm _saying_ to create a completely separate counter which has nothing to > > > > do with accounting. > > > > > > See above. > > > > I did see above. If the sole purpose of a counter is to turn _off_ a > > feature to prevent DoS attacks, and it is clearly desirable that the > > admin (or a representative entity such as a monitoring system) would > > want to be able to re-enable the logging under those same terms at some > > admin-specified interval, how exactly would you choose to implement this? > > What was originally intended and what it's used for now are two > different things. I agree; the function of verbose log limiting was overloaded onto the existing accounting counter. That is why I am saying that this really, really should be made into a separate log counter, whose sole function in life is counting for the purpose of determining VERBOSE_LIMIT excesses. I am not sure why you seem to have a problem with that. If I have a mechanism that exists for _one_ purpose and one purpose alone, why is it unacceptable to perform operation "X" (where X == zero it) on said device when that is an action that will cause it to work in a desired manner? > I'd like to see people other than you, I, and Matt discussing this. > Other people who use this feature of IPFW that have an opinion one way > or the other should speak up. > > A group of two very opinionated people doesn't make a consensus, or > necessarily the 'right' decision. :) :) :) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 13:11:57 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id A9FF114E2C; Tue, 27 Jul 1999 13:11:47 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id NAA01865; Tue, 27 Jul 1999 13:08:25 -0700 (PDT) Date: Tue, 27 Jul 1999 13:08:24 -0700 (PDT) From: Julian Elischer To: Joe Greco Cc: Nate Williams , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271949.OAA13262@aurora.sol.net> 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 a system wide limit and each rule's logging counter individually resetable back to 0. On Tue, 27 Jul 1999, Joe Greco wrote: > > 1) Set a global VERBOSE_LIMIT mechanism and: > a) allow your logging counter to be reset, or > b) allow your limit to be raised to re-enable logging > 2) Set a rule-oriented VERBOSE_LIMIT mechanism and allow each rule's > logging counter to be reset. > > So, what's your vote? > > (I'm wondering if maybe we can do a combined 1a and 2 of some sort) > > ... Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 13:24:29 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from gemini.bnc.net (gemini.bnc.net [195.247.233.33]) by hub.freebsd.org (Postfix) with ESMTP id BFC9015481; Tue, 27 Jul 1999 13:23:45 -0700 (PDT) (envelope-from ap@bnc.net) Received: (from ap@localhost) by gemini.bnc.net (8.9.3/8.9.3) id WAA75174; Tue, 27 Jul 1999 22:20:33 +0200 (CEST) (envelope-from ap) Date: Tue, 27 Jul 1999 22:20:33 +0200 From: Achim Patzner To: Nate Williams Cc: Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero Message-ID: <19990727222033.A75086@bnc.net> References: <199907271951.NAA27049@mt.sri.com> <199907271956.OAA13811@aurora.sol.net> <199907271959.NAA27155@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907271959.NAA27155@mt.sri.com>; from Nate Williams on Tue, Jul 27, 1999 at 01:59:58PM -0600 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'd like to see people other than you, I, and Matt discussing this. > Other people who use this feature of IPFW that have an opinion one way > or the other should speak up. I must admit being a bad boy - I'm using ipfw for firewalling and accounting: "log" rules for catching bad guys (and I'm not caring for a limit there as I'm preferring a DoS by crashing the firewall over someone getting through unnoticed) and the counters for accounting (that's why I'd like to have some "read and reset" function so I can milk them without dripping too much). Achim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 19:50:24 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 4F12914C1A; Tue, 27 Jul 1999 19:50:20 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id WAA67212; Tue, 27 Jul 1999 22:48:46 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 27 Jul 1999 22:48:46 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Nate Williams Cc: Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907271915.NAA26782@mt.sri.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 If it will get ALL of you to give it a rest, how about: per-rule logging limits logging limit raising logging limit resetting Which would all NOT affect the statistics? I am, yes, suggesting I will implement it. Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.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 Jul 27 21:50:52 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 75C2D14DC3; Tue, 27 Jul 1999 21:50:44 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id WAA24109; Tue, 27 Jul 1999 22:49:03 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id WAA29417; Tue, 27 Jul 1999 22:49:02 -0600 Date: Tue, 27 Jul 1999 22:49:02 -0600 Message-Id: <199907280449.WAA29417@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Brian F. Feldman" Cc: Nate Williams , Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: References: <199907271915.NAA26782@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If it will get ALL of you to give it a rest, how about: > per-rule logging limits > logging limit raising > logging limit resetting > Which would all NOT affect the statistics? We need more input from people who use the code, to make sure they don't depend on the current 'features', or can live with changes to them. Implementing it is the easy part, making sure it's the right thing to do is the hard part. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 27 23:20:36 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 395C815416; Tue, 27 Jul 1999 23:20:29 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id CAA71895; Wed, 28 Jul 1999 02:19:06 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 28 Jul 1999 02:19:06 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Nate Williams Cc: Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907280449.WAA29417@mt.sri.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 Tue, 27 Jul 1999, Nate Williams wrote: > > If it will get ALL of you to give it a rest, how about: > > per-rule logging limits > > logging limit raising > > logging limit resetting > > Which would all NOT affect the statistics? > > We need more input from people who use the code, to make sure they don't > depend on the current 'features', or can live with changes to them. > > Implementing it is the easy part, making sure it's the right thing to do > is the hard part. Well, the easy part is done, except for raising limits. Look: ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 ipfw: limit 2 reached on rule #1 ipfw: Entry 1 logging count reset. ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 ipfw: limit 2 reached on rule #1 Nice? :) I think this feature should DEFINITELY go in. I'm going to clean it up some (ip_fw.c itself), and then make a set of diffs for this feature. > > > Nate > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 1:14:51 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from itesec.hsc.fr (itesec.hsc.fr [192.70.106.33]) by hub.freebsd.org (Postfix) with ESMTP id 2881414E91 for ; Wed, 28 Jul 1999 01:14:47 -0700 (PDT) (envelope-from Alain.Thivillon@hsc.fr) Received: from yoko.hsc.fr (yoko.hsc.fr [192.70.106.76]) by itesec.hsc.fr (Postfix) with ESMTP id 45AE910EAE; Wed, 28 Jul 1999 10:14:47 +0200 (CEST) Received: by yoko.hsc.fr (Postfix release-19990601, from userid 1001) id ED1F112FEE0; Wed, 28 Jul 1999 10:14:27 +0200 (CEST) Date: Wed, 28 Jul 1999 10:14:27 +0200 From: Alain Thivillon To: Scott Taylor Cc: freebsd-ipfw@freebsd.org Subject: Re: reflexive access lists? Message-ID: <19990728101427.E28741@yoko.hsc.fr> References: <379DED83.70D4B4BE@graphicexpress.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.95.5i In-Reply-To: <379DED83.70D4B4BE@graphicexpress.net>; from Scott Taylor on Tue, Jul 27, 1999 at 11:33:55AM -0600 X-Organization: Herve Schauer Consultants Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Scott Taylor écrivait (wrote) : > One of the rules that I have in the access lists on my cisco routers > that I wish I could setup of my freebsd box are reflexive access lists. > I'd love to be able to allow packets that are replies to requests from > my machine be automatically allowed without allowing such a blanket ipfilter use "keep state" to store information about sessions and open up dynamically tcp, udp and even icmp 'reflexive' flow. If i want enable all outgoing connections from my box, and block everything else (warning, this will be a very bas setup if this box is a router): pass out quick on lo0 from any to any pass in quick on lo0 from any to any block in log quick from any to any with ipopts block in log quick proto tcp from any to any with short pass out quick proto tcp from any to any keep state pass out quick proto udp from any to any keep state pass out quick proto icmp from any to any keep state block return-rst in log quick proto tcp from any to any block return-icmp(port-unr) in log quick proto udp from any to any block return-icmp(13) in log from any to any To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 8:14:27 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.anp.nl (ns.anp.nl [195.81.24.2]) by hub.freebsd.org (Postfix) with ESMTP id 0F53E14D85; Wed, 28 Jul 1999 08:14:21 -0700 (PDT) (envelope-from hvoers@anp.nl) Received: from ns.anp.nl (ns.anp.nl [195.81.24.2]) by ns.anp.nl (8.9.1/8.9.1) with SMTP id RAA16166; Wed, 28 Jul 1999 17:11:36 +0200 Date: Wed, 28 Jul 1999 17:11:36 +0200 (cest) From: Henk van Oers To: "Brian F. Feldman" Cc: Nate Williams , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: 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 Wed, 28 Jul 1999, Brian F. Feldman wrote: > > > If it will get ALL of you to give it a rest, how about: > > > per-rule logging limits > > > logging limit raising > > > logging limit resetting > > > Which would all NOT affect the statistics? Separate statistics/logging counters is fine, but i don't need per-rule limits, a global limit is ok --> sysctl -w for raising and ipfw zerolog (or reset) for resetting. And then ... securelevel == 3 I think it is better NOT to permit 'sysctl -w', 'ipfw *' AND a logging limmit, just process the logfile faster to avoid DoS > > > > We need more input from people who use the code, to make sure they don't > > depend on the current 'features', or can live with changes to them. If you can keep the foot print small i can live with it. > > > > Implementing it is the easy part, making sure it's the right thing to do > > is the hard part. Right! > > Well, the easy part is done, except for raising limits. Look: > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: limit 2 reached on rule #1 > ipfw: Entry 1 logging count reset. > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: limit 2 reached on rule #1 > > I think this feature should DEFINITELY go in. I'm going to clean it up some > (ip_fw.c itself), and then make a set of diffs for this feature. > Nice? :) Nice? Depends on the diffs AND the man page ;-) Henk. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 8:19:58 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.anp.nl (ns.anp.nl [195.81.24.2]) by hub.freebsd.org (Postfix) with ESMTP id 1FBBF14FDA; Wed, 28 Jul 1999 08:19:54 -0700 (PDT) (envelope-from hvoers@anp.nl) Received: from ns.anp.nl (ns.anp.nl [195.81.24.2]) by ns.anp.nl (8.9.1/8.9.1) with SMTP id RAA19051; Wed, 28 Jul 1999 17:16:04 +0200 Date: Wed, 28 Jul 1999 17:16:04 +0200 (cest) From: Henk van Oers To: Julian Elischer Cc: Joe Greco , Nate Williams , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: 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 Tue, 27 Jul 1999, Julian Elischer wrote: > a system wide limit and each rule's logging counter individually resetable > back to 0. > > So, what's your vote? > > ... Joe I vote for this too. Henk. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 8:39:43 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 4AAED15521; Wed, 28 Jul 1999 08:39:34 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id JAA01528; Wed, 28 Jul 1999 09:38:21 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA01258; Wed, 28 Jul 1999 09:38:20 -0600 Date: Wed, 28 Jul 1999 09:38:20 -0600 Message-Id: <199907281538.JAA01258@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Henk van Oers Cc: "Brian F. Feldman" , Nate Williams , Joe Greco , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > And then ... securelevel == 3 I think it is better NOT to permit > 'sysctl -w', 'ipfw *' AND a logging limmit, just process the logfile > faster to avoid DoS The real issue we are dealing with is what happens at securelevel == 3. What you are saying is that people shouldn't be allowed to modify *anything* at securelevel == 3, correct? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 8:40:54 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id BAB00154D0; Wed, 28 Jul 1999 08:40:48 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id JAA01548; Wed, 28 Jul 1999 09:39:45 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA01265; Wed, 28 Jul 1999 09:39:44 -0600 Date: Wed, 28 Jul 1999 09:39:44 -0600 Message-Id: <199907281539.JAA01265@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Brian F. Feldman" Cc: Nate Williams , Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: References: <199907280449.WAA29417@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Implementing it is the easy part, making sure it's the right thing to do > > is the hard part. > > Well, the easy part is done, except for raising limits. Look: > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: limit 2 reached on rule #1 > ipfw: Entry 1 logging count reset. > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: limit 2 reached on rule #1 > > Nice? :) Depends on how it effects the speed of the system and if it makes the code too complex. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 10:43:53 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from t47.tempest.sk (t47.tempest.sk [195.28.100.47]) by hub.freebsd.org (Postfix) with ESMTP id A350414CC6 for ; Wed, 28 Jul 1999 10:43:12 -0700 (PDT) (envelope-from ludo_koren@tempest.sk) Received: (from koren@localhost) by t47.tempest.sk (8.9.3/8.9.3) id TAA94386; Wed, 28 Jul 1999 19:43:09 +0200 (CEST) (envelope-from koren) Date: Wed, 28 Jul 1999 19:43:09 +0200 (CEST) Message-Id: <199907281743.TAA94386@t47.tempest.sk> From: Ludo Koren To: freebsd-ipfw@freebsd.org Subject: ipfw forwarding Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi. I am running 3.2-STABLE with these relevant kernel options: options BRIDGE options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #print information about # dropped packets options IPFIREWALL_FORWARD #enable transparent proxy support #options "IPFIREWALL_VERBOSE_LIMIT=100" #limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default #options IPDIVERT #divert sockets options DUMMYNET The relevant kernel variables: net.link.ether.bridge: 1 net.link.ether.bridge_ipfw: 1 ipfw is configured as follows: 00400 allow log tcp from 195.28.100.104 to any via xl0 00500 fwd 127.0.0.1,80 log tcp from any to any 80 60000 allow log tcp from any to any 65535 allow ip from any to any Squid cache is listening on the port 80. I am trying to do a transparent caching. If I configure browser as directly connected to the Internet everything works ok but the cache doesn't store any pages. If I manually configure proxy in the browser, the cache works. Do I understand the ipfw man page right or am I missing something? Should the cache work transparently in the above mentioned configuration? What's the purpose of the ipfw forwarding? Any help is greatly appreciated. Thanks. ludo PS: the ipfw kernel log follows: Jul 28 19:40:26 lk104 /kernel: ipfw: 500 Forward to 127.0.0.1:80 TCP 195.28.100.106:1057 195.28.100.6:80 in via ep0 Jul 28 19:40:26 lk104 /kernel: ipfw: 500 Forward to 127.0.0.1:80 TCP 195.28.100. 106:1057 195.28.100.6:80 in via ep0 Jul 28 19:40:26 lk104 /kernel: ipfw: 60000 Accept TCP 195.28.100.6:80 195.28.100 .106:1057 in via xl0 Jul 28 19:40:26 lk104 /kernel: ipfw: 60000 Accept TCP 195.28.100.6:80 195.28.100 .106:1057 in via xl0 Jul 28 19:40:26 lk104 /kernel: ipfw: 500 Forward to 127.0.0.1:80 TCP 195.28.100. 106:1057 195.28.100.6:80 in via ep0 Jul 28 19:40:26 lk104 /kernel: ipfw: 500 Forward to 127.0.0.1:80 TCP 195.28.100. 106:1057 195.28.100.6:80 in via ep0 Jul 28 19:40:26 lk104 /kernel: ipfw: 500 Forward to 127.0.0.1:80 TCP 195.28.100. 106:1057 195.28.100.6:80 in via ep0 Jul 28 19:40:26 lk104 /kernel: ipfw: 60000 Accept TCP 195.28.100.6:80 195.28.100 .106:1057 in via xl0 Jul 28 19:40:26 lk104 /kernel: ipfw: 500 Forward to 127.0.0.1:80 TCP 195.28.100. 106:1057 195.28.100.6:80 in via ep0 Jul 28 19:40:26 lk104 /kernel: ipfw: 60000 Accept TCP 195.28.100.6:80 195.28.100 .106:1057 in via xl0 Jul 28 19:40:26 lk104 /kernel: ipfw: 60000 Accept TCP 195.28.100.6:80 195.28.100 .106:1057 in via xl0 Jul 28 19:40:26 lk104 /kernel: ipfw: 500 Forward to 127.0.0.1:80 TCP 195.28.100. 106:1058 195.28.100.6:80 in via ep0 Jul 28 19:40:26 lk104 /kernel: ipfw: 60000 Accept TCP 195.28.100.6:80 195.28.100 .106:1057 in via xl0 Jul 28 19:40:26 lk104 /kernel: ipfw: 500 Forward to 127.0.0.1:80 TCP 195.28.100. 106:1058 195.28.100.6:80 in via ep0 Jul 28 19:40:26 lk104 /kernel: ipfw: 60000 Accept TCP 195.28.100.6:80 195.28.100 .106:1058 in via xl0 Jul 28 19:40:26 lk104 /kernel: ipfw: 60000 Accept TCP 195.28.100.6:80 195.28.100 .106:1058 in via xl0 Jul 28 19:40:26 lk104 /kernel: ipfw: 500 Forward to 127.0.0.1:80 TCP 195.28.100. 106:1058 195.28.100.6:80 in via ep0 Jul 28 19:40:26 lk104 /kernel: ipfw: 500 Forward to 127.0.0.1:80 TCP 195.28.100. 106:1058 195.28.100.6:80 in via ep0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 12:14:49 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 404C414CF3; Wed, 28 Jul 1999 12:14:42 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id MAA11893; Wed, 28 Jul 1999 12:12:29 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Wed, 28 Jul 1999 12:12:28 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: "Brian F. Feldman" Cc: Nate Williams , Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: 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 Tue, 27 Jul 1999, Brian F. Feldman wrote: > If it will get ALL of you to give it a rest, how about: > per-rule logging limits This has been needed for some time now. Also, please don't forget the oft-repeated request to have seperate accounting and logging counters so that you can zero one, but not the other. > logging limit raising > logging limit resetting I'd say that these are good knobs to have (I assume you're talking sysctl's?) but I'd also like to suggest a knob that allows you to toggle whether these can be changed at securelevel > 1, which knob is not resettable at securelevel > 1. I think that this would answer the needs of all parties concerned. > Which would all NOT affect the statistics? Oh good, you didn't forget. :) > I am, yes, suggesting I will implement it. Coolio. And inre the request to hear from the users of the code, I am one, have been for years, and deploy it in many different environments (including natd, basic security, etc.). These would be very welcome additions assuming that the performance hit is negligible. Thanks, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 12:35: 1 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 8E1181556B; Wed, 28 Jul 1999 12:34:52 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id PAA92882; Wed, 28 Jul 1999 15:33:35 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 28 Jul 1999 15:33:34 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Nate Williams Cc: Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907281539.JAA01265@mt.sri.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 Wed, 28 Jul 1999, Nate Williams wrote: > > > Implementing it is the easy part, making sure it's the right thing to do > > > is the hard part. > > > > Well, the easy part is done, except for raising limits. Look: > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > ipfw: limit 2 reached on rule #1 > > ipfw: Entry 1 logging count reset. > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > ipfw: limit 2 reached on rule #1 > > > > Nice? :) > > Depends on how it effects the speed of the system and if it makes the > code too complex. :) None and no. > > > Nate > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 12:38:54 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 08E9114FEE; Wed, 28 Jul 1999 12:38:44 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id NAA04448; Wed, 28 Jul 1999 13:37:18 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA02547; Wed, 28 Jul 1999 13:37:17 -0600 Date: Wed, 28 Jul 1999 13:37:17 -0600 Message-Id: <199907281937.NAA02547@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Brian F. Feldman" Cc: Nate Williams , Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: References: <199907281539.JAA01265@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > Implementing it is the easy part, making sure it's the right thing to do > > > > is the hard part. > > > > > > Well, the easy part is done, except for raising limits. Look: > > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > > ipfw: limit 2 reached on rule #1 > > > ipfw: Entry 1 logging count reset. > > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > > ipfw: limit 2 reached on rule #1 > > > > > > Nice? :) > > > > Depends on how it effects the speed of the system and if it makes the > > code too complex. :) > > None and no. Beauty is in the eye of the beholder. Let's suspend judgement on it until we actually get a chance to review it, pride in your work not withstanding. :) :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 12:57:30 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id B05D015033; Wed, 28 Jul 1999 12:57:19 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id PAA93305; Wed, 28 Jul 1999 15:54:55 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 28 Jul 1999 15:54:55 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Nate Williams Cc: Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907281937.NAA02547@mt.sri.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 I need help finishing it. The ipfw.8 manpage isn't quite fixed yet. When someone will do that, it will be Ready :) But I've attached it! Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ Index: src/sbin/ipfw/ipfw.8 =================================================================== RCS file: /home/ncvs/src/sbin/ipfw/ipfw.8,v retrieving revision 1.54 diff -u -r1.54 ipfw.8 --- ipfw.8 1999/06/19 18:43:18 1.54 +++ ipfw.8 1999/07/28 19:35:31 @@ -50,6 +50,7 @@ .Op Ar number .Ar action .Op log +.Op Ar logamount Ar number .Ar proto from .Ar src Index: src/sbin/ipfw/ipfw.c =================================================================== RCS file: /home/ncvs/src/sbin/ipfw/ipfw.c,v retrieving revision 1.71 diff -u -r1.71 ipfw.c --- ipfw.c 1999/06/19 18:43:15 1.71 +++ ipfw.c 1999/07/28 06:15:08 @@ -27,6 +27,7 @@ #include #include #include +#include #include #include @@ -247,8 +248,11 @@ errx(EX_OSERR, "impossible"); } - if (chain->fw_flg & IP_FW_F_PRN) + if (chain->fw_flg & IP_FW_F_PRN) { printf(" log"); + if (chain->fw_logamount) + printf(" logamount %d", chain->fw_logamount); + } pe = getprotobynumber(chain->fw_prot); if (pe) @@ -599,12 +603,13 @@ " [pipe] list [number ...]\n" " [pipe] show [number ...]\n" " zero [number ...]\n" +" resetlog [number ...]\n" " pipe number config [pipeconfig]\n" " rule: action proto src dst extras...\n" " action:\n" " {allow|permit|accept|pass|deny|drop|reject|unreach code|\n" " reset|count|skipto num|divert port|tee port|fwd ip|\n" -" pipe num} [log]\n" +" pipe num} [log [logamount count]]\n" " proto: {ip|tcp|udp|icmp|}\n" " src: from [not] {any|ip[{/bits|:mask}]} [{port|port-port},[port],...]\n" " dst: to [not] {any|ip[{/bits|:mask}]} [{port|port-port},[port],...]\n" @@ -1164,6 +1169,18 @@ if (ac && !strncmp(*av,"log",strlen(*av))) { rule.fw_flg |= IP_FW_F_PRN; av++; ac--; } + if (ac && !strncmp(*av,"logamount",strlen(*av))) { + if (!(rule.fw_flg & IP_FW_F_PRN)) + show_usage("``logamount'' not valid without ``log''"); + ac--; av++; + if (!ac) + show_usage("``logamount'' requires argument"); + rule.fw_logamount = atoi(*av); + if (rule.fw_logamount <= 0) + show_usage("``logamount'' argument must be greater " + "than 0"); + ac--; av++; + } /* protocol */ if (ac == 0) @@ -1385,7 +1402,18 @@ if (rule.fw_nports) show_usage("can't mix 'frag' and port specifications"); } - + if (rule.fw_flg & IP_FW_F_PRN) { + if (!rule.fw_logamount) { + size_t len = sizeof(int); + + if (sysctlbyname("net.inet.ip.fw.verbose_limit", + &rule.fw_logamount, &len, NULL, 0) == -1) + errx(1, "sysctlbyname(\"%s\")", + "net.inet.ip.fw.verbose_limit"); + } + rule.fw_loghighest = rule.fw_logamount; + } + if (!do_quiet) show_ipfw(&rule, 10, 10); i = setsockopt(s, IPPROTO_IP, IP_FW_ADD, &rule, sizeof rule); @@ -1432,6 +1460,45 @@ } } +static void +resetlog (ac, av) + int ac; + char **av; +{ + av++; ac--; + + if (!ac) { + /* clear all entries */ + if (setsockopt(s,IPPROTO_IP,IP_FW_RESETLOG,NULL,0)<0) + err(EX_UNAVAILABLE, "setsockopt(%s)", "IP_FW_RESETLOG"); + if (!do_quiet) + printf("Logging counts reset.\n"); + } else { + struct ip_fw rule; + int failed = EX_OK; + + memset(&rule, 0, sizeof rule); + while (ac) { + /* Rule number */ + if (isdigit(**av)) { + rule.fw_number = atoi(*av); av++; ac--; + if (setsockopt(s, IPPROTO_IP, + IP_FW_RESETLOG, &rule, sizeof rule)) { + warn("rule %u: setsockopt(%s)", rule.fw_number, + "IP_FW_RESETLOG"); + failed = EX_UNAVAILABLE; + } + else if (!do_quiet) + printf("Entry %d logging count reset\n", + rule.fw_number); + } else + show_usage("invalid rule number ``%s''", *av); + } + if (failed != EX_OK) + exit(failed); + } +} + static int ipfw_main(ac,av) int ac; @@ -1527,6 +1594,8 @@ } } else if (!strncmp(*av, "zero", strlen(*av))) { zero(ac,av); + } else if (!strncmp(*av, "resetlog", strlen(*av))) { + resetlog(ac,av); } else if (!strncmp(*av, "print", strlen(*av))) { list(--ac,++av); } else if (!strncmp(*av, "list", strlen(*av))) { Index: src/sys/netinet/ip_fw.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v retrieving revision 1.114 diff -u -r1.114 ip_fw.c --- ip_fw.c 1999/06/19 18:43:28 1.114 +++ ip_fw.c 1999/07/28 06:29:07 @@ -106,6 +106,7 @@ static int add_entry __P((struct ip_fw_head *chainptr, struct ip_fw *frwl)); static int del_entry __P((struct ip_fw_head *chainptr, u_short number)); static int zero_entry __P((struct ip_fw *)); +static int resetlog_entry __P((struct ip_fw *)); static int check_ipfw_struct __P((struct ip_fw *m)); static __inline int iface_match __P((struct ifnet *ifp, union ip_fw_if *ifu, @@ -184,8 +185,8 @@ /* check for matching type in the bitmap */ if (type < IP_FW_ICMPTYPES_MAX && - (f->fw_uar.fw_icmptypes[type / (sizeof(unsigned) * 8)] & - (1U << (type % (8 * sizeof(unsigned)))))) + (f->fw_uar.fw_icmptypes[type / (sizeof(unsigned) * NBBY)] & + (1U << (type % (sizeof(unsigned) * NBBY))))) return(1); return(0); /* no match */ @@ -302,14 +303,15 @@ struct ifnet *rif, struct ifnet *oif) { if (ip) { + struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip->ip_hl); + struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip->ip_hl); + struct icmp *const icmp = (struct icmp *)((u_int32_t *)ip+ip->ip_hl); static u_int64_t counter; - struct tcphdr *const tcp = (struct tcphdr *) ((u_int32_t *) ip+ ip->ip_hl); - struct udphdr *const udp = (struct udphdr *) ((u_int32_t *) ip+ ip->ip_hl); - struct icmp *const icmp = (struct icmp *) ((u_int32_t *) ip + ip->ip_hl); - int count; + u_int64_t count; count = f ? f->fw_pcnt : ++counter; - if (fw_verbose_limit != 0 && count > fw_verbose_limit) + if ((f == NULL && fw_verbose_limit != 0 && count > fw_verbose_limit) || + (f && f->fw_logamount != 0 && count > f->fw_loghighest)) return; /* Print command name */ @@ -406,12 +408,13 @@ printf(" out via %s%d", oif->if_name, oif->if_unit); else if (rif) printf(" in via %s%d", rif->if_name, rif->if_unit); - if ((ip->ip_off & IP_OFFMASK)) - printf(" Fragment = %d",ip->ip_off & IP_OFFMASK); + if (ip->ip_off & IP_OFFMASK) + printf(" Fragment = %d", ip->ip_off & IP_OFFMASK); printf("\n"); - if (fw_verbose_limit != 0 && count == fw_verbose_limit) - printf("ipfw: limit reached on rule #%d\n", - f ? f->fw_number : -1); + if ((f ? f->fw_logamount != 0 : 1) && + count == (f ? f->fw_loghighest : fw_verbose_limit)) + printf("ipfw: limit %d reached on rule #%d\n", + f ? f->fw_logamount : fw_verbose_limit, f ? f->fw_number : -1); } } @@ -1108,6 +1111,55 @@ } static int +resetlog_entry(struct ip_fw *frwl) +{ + struct ip_fw_chain *fcp; + int s, cleared; + + if (frwl == 0) { + s = splnet(); + for (fcp = LIST_FIRST(&ip_fw_chain); fcp; fcp = LIST_NEXT(fcp, chain)) + fcp->rule->fw_loghighest = fcp->rule->fw_pcnt + + fcp->rule->fw_logamount; + splx(s); + } + else { + cleared = 0; + + /* + * It's possible to insert multiple chain entries with the + * same number, so we don't stop after finding the first + * match if zeroing a specific entry. + */ + for (fcp = LIST_FIRST(&ip_fw_chain); fcp; fcp = LIST_NEXT(fcp, chain)) + if (frwl->fw_number == fcp->rule->fw_number) { + s = splnet(); + while (fcp && frwl->fw_number == fcp->rule->fw_number) { + fcp->rule->fw_loghighest = + fcp->rule->fw_pcnt + + fcp->rule->fw_logamount; + fcp = LIST_NEXT(fcp, chain); + } + splx(s); + cleared = 1; + break; + } + if (!cleared) /* we didn't find any matching rules */ + return (EINVAL); + } + + if (fw_verbose) { + if (frwl) + printf("ipfw: Entry %d logging count reset.\n", + frwl->fw_number); + else + printf("ipfw: All logging counts cleared.\n"); + } + + return (0); +} + +static int check_ipfw_struct(struct ip_fw *frwl) { /* Check for invalid flag bits */ @@ -1320,6 +1372,17 @@ } break; + case IP_FW_RESETLOG: + if (sopt->sopt_val != 0) { + error = sooptcopyin(sopt, &frwl, sizeof frwl, + sizeof frwl); + if (error || (error = resetlog_entry(&frwl))) + break; + } else { + error = resetlog_entry(0); + } + break; + default: printf("ip_fw_ctl invalid option %d\n", sopt->sopt_name); error = EINVAL ; @@ -1373,7 +1436,7 @@ if (fw_verbose_limit == 0) printf("unlimited logging\n"); else - printf("logging limited to %d packets/entry\n", + printf("logging limited to %d packets/entry by default\n", fw_verbose_limit); #endif } Index: src/sys/netinet/ip_fw.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw.h,v retrieving revision 1.38 diff -u -r1.38 ip_fw.h --- ip_fw.h 1999/06/19 18:43:30 1.38 +++ ip_fw.h 1999/07/28 05:08:07 @@ -75,14 +75,18 @@ struct sockaddr_in fu_fwd_ip; } fw_un; u_char fw_prot; /* IP protocol */ - u_char fw_nports; /* N'of src ports and # of dst ports */ - /* in ports array (dst ports follow */ - /* src ports; max of 10 ports in all; */ - /* count of 0 means match all ports) */ - void *pipe_ptr; /* Pipe ptr in case of dummynet pipe */ - void *next_rule_ptr ; /* next rule in case of match */ + u_char fw_nports; /* + * N'of src ports and # of dst ports + * in ports array (dst ports follow + * src ports; max of 10 ports in all; + * count of 0 means match all ports) + */ + void *pipe_ptr; /* pipe ptr in case of dummynet pipe */ + void *next_rule_ptr; /* next rule in case of match */ uid_t fw_uid; /* uid to match */ gid_t fw_gid; /* gid to match */ + int fw_logamount; /* amount to log */ + u_int64_t fw_loghighest; /* highest number packet to log */ }; #define IP_FW_GETNSRCP(rule) ((rule)->fw_nports & 0x0f) Index: src/sys/netinet/in.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/in.h,v retrieving revision 1.42 diff -u -r1.42 in.h --- in.h 1999/05/08 14:28:52 1.42 +++ in.h 1999/07/28 05:46:20 @@ -322,6 +322,7 @@ #define IP_FW_FLUSH 52 /* flush firewall rule chain */ #define IP_FW_ZERO 53 /* clear single/all firewall counter(s) */ #define IP_FW_GET 54 /* get entire firewall rule chain */ +#define IP_FW_RESETLOG 55 /* reset logging counters */ #define IP_DUMMYNET_CONFIGURE 60 /* add/configure a dummynet pipe */ #define IP_DUMMYNET_DEL 61 /* delete a dummynet pipe from chain */ Index: src/sys/netinet/raw_ip.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/raw_ip.c,v retrieving revision 1.59 diff -u -r1.59 raw_ip.c --- raw_ip.c 1999/05/03 23:57:30 1.59 +++ raw_ip.c 1999/07/28 06:07:59 @@ -293,6 +293,7 @@ case IP_FW_DEL: case IP_FW_FLUSH: case IP_FW_ZERO: + case IP_FW_RESETLOG: if (ip_fw_ctl_ptr == 0) error = ENOPROTOOPT; else To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 13: 1:31 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 30F7415033; Wed, 28 Jul 1999 13:01:25 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id OAA04762; Wed, 28 Jul 1999 14:00:07 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA02728; Wed, 28 Jul 1999 14:00:06 -0600 Date: Wed, 28 Jul 1999 14:00:06 -0600 Message-Id: <199907282000.OAA02728@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Brian F. Feldman" Cc: Nate Williams , Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: References: <199907281937.NAA02547@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Index: src/sys/netinet/ip_fw.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v > retrieving revision 1.114 > diff -u -r1.114 ip_fw.c > --- ip_fw.c 1999/06/19 18:43:28 1.114 > +++ ip_fw.c 1999/07/28 06:29:07 > @@ -106,6 +106,7 @@ > static int add_entry __P((struct ip_fw_head *chainptr, struct ip_fw *frwl)); > static int del_entry __P((struct ip_fw_head *chainptr, u_short number)); > static int zero_entry __P((struct ip_fw *)); > +static int resetlog_entry __P((struct ip_fw *)); > static int check_ipfw_struct __P((struct ip_fw *m)); > static __inline int > iface_match __P((struct ifnet *ifp, union ip_fw_if *ifu, > @@ -184,8 +185,8 @@ > > /* check for matching type in the bitmap */ > if (type < IP_FW_ICMPTYPES_MAX && > - (f->fw_uar.fw_icmptypes[type / (sizeof(unsigned) * 8)] & > - (1U << (type % (8 * sizeof(unsigned)))))) > + (f->fw_uar.fw_icmptypes[type / (sizeof(unsigned) * NBBY)] & > + (1U << (type % (sizeof(unsigned) * NBBY))))) > return(1); > > return(0); /* no match */ These are good bugfixes, and should be committed seperately. > @@ -302,14 +303,15 @@ > struct ifnet *rif, struct ifnet *oif) > { > if (ip) { > + struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip->ip_hl); > + struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip->ip_hl); > + struct icmp *const icmp = (struct icmp *)((u_int32_t *)ip+ip->ip_hl); > static u_int64_t counter; > - struct tcphdr *const tcp = (struct tcphdr *) ((u_int32_t *) ip+ ip->ip_hl); > - struct udphdr *const udp = (struct udphdr *) ((u_int32_t *) ip+ ip->ip_hl); > - struct icmp *const icmp = (struct icmp *) ((u_int32_t *) ip + ip->ip_hl); > - int count; > + u_int64_t count; These are mostly change for changes sake, and make it difficult to see the functional changes. Please limit your changes to changes, and not just to add stylistic differences. While I may agree with them, they detract from the review process. [ Rest deleted ] Can you resend them to me in private email after you remove the white-space/stylistic changes? Thanks! Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 13: 7:39 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 8EDCD15647; Wed, 28 Jul 1999 13:07:23 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id QAA93553; Wed, 28 Jul 1999 16:05:53 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 28 Jul 1999 16:05:53 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Nate Williams Cc: Joe Greco , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907282000.OAA02728@mt.sri.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 Wed, 28 Jul 1999, Nate Williams wrote: > > Index: src/sys/netinet/ip_fw.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v > > retrieving revision 1.114 > > diff -u -r1.114 ip_fw.c > > --- ip_fw.c 1999/06/19 18:43:28 1.114 > > +++ ip_fw.c 1999/07/28 06:29:07 > > @@ -106,6 +106,7 @@ > > static int add_entry __P((struct ip_fw_head *chainptr, struct ip_fw *frwl)); > > static int del_entry __P((struct ip_fw_head *chainptr, u_short number)); > > static int zero_entry __P((struct ip_fw *)); > > +static int resetlog_entry __P((struct ip_fw *)); > > static int check_ipfw_struct __P((struct ip_fw *m)); > > static __inline int > > iface_match __P((struct ifnet *ifp, union ip_fw_if *ifu, > > @@ -184,8 +185,8 @@ > > > > /* check for matching type in the bitmap */ > > if (type < IP_FW_ICMPTYPES_MAX && > > - (f->fw_uar.fw_icmptypes[type / (sizeof(unsigned) * 8)] & > > - (1U << (type % (8 * sizeof(unsigned)))))) > > + (f->fw_uar.fw_icmptypes[type / (sizeof(unsigned) * NBBY)] & > > + (1U << (type % (sizeof(unsigned) * NBBY))))) > > return(1); > > > > return(0); /* no match */ > > These are good bugfixes, and should be committed seperately. Yes, this specific part shouldn't go in the same commit. > > > @@ -302,14 +303,15 @@ > > struct ifnet *rif, struct ifnet *oif) > > { > > if (ip) { > > + struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip->ip_hl); > > + struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip->ip_hl); > > + struct icmp *const icmp = (struct icmp *)((u_int32_t *)ip+ip->ip_hl); > > static u_int64_t counter; > > - struct tcphdr *const tcp = (struct tcphdr *) ((u_int32_t *) ip+ ip->ip_hl); > > - struct udphdr *const udp = (struct udphdr *) ((u_int32_t *) ip+ ip->ip_hl); > > - struct icmp *const icmp = (struct icmp *) ((u_int32_t *) ip + ip->ip_hl); > > - int count; > > + u_int64_t count; > > These are mostly change for changes sake, and make it difficult to see > the functional changes. Please limit your changes to changes, and not > just to add stylistic differences. While I may agree with them, they > detract from the review process. These were changes that were necessary to make ipfw readable enough that I could work with it in this area. They aren't just to clean it up, or just for change's sake. They need to stay in. > > [ Rest deleted ] > > Can you resend them to me in private email after you remove the > white-space/stylistic changes? Thanks! > > > > Nate > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 13: 9:44 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 2A12D154B1; Wed, 28 Jul 1999 13:09:38 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id OAA04881; Wed, 28 Jul 1999 14:08:50 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA02877; Wed, 28 Jul 1999 14:08:49 -0600 Date: Wed, 28 Jul 1999 14:08:49 -0600 Message-Id: <199907282008.OAA02877@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Brian F. Feldman" Cc: Nate Williams , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: References: <199907282000.OAA02728@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > @@ -302,14 +303,15 @@ > > > struct ifnet *rif, struct ifnet *oif) > > > { > > > if (ip) { > > > + struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip->ip_hl); > > > + struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip->ip_hl); > > > + struct icmp *const icmp = (struct icmp *)((u_int32_t *)ip+ip->ip_hl); > > > static u_int64_t counter; > > > - struct tcphdr *const tcp = (struct tcphdr *) ((u_int32_t *) ip+ ip->ip_hl); > > > - struct udphdr *const udp = (struct udphdr *) ((u_int32_t *) ip+ ip->ip_hl); > > > - struct icmp *const icmp = (struct icmp *) ((u_int32_t *) ip + ip->ip_hl); > > > - int count; > > > + u_int64_t count; > > > > These are mostly change for changes sake, and make it difficult to see > > the functional changes. Please limit your changes to changes, and not > > just to add stylistic differences. While I may agree with them, they > > detract from the review process. > > These were changes that were necessary to make ipfw readable enough that > I could work with it in this area. They aren't just to clean it up, or > just for change's sake. They need to stay in. C'mon now, re-ording the lines is *certainly* not necessary to work. *rant on* Brian, FreeBSD isn't your private playground for playing around, this is a group project, and you gotta follow the rules, or you don't get to play with the rest of the folks.... *rant off* Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 13:18: 9 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 0F474153FA; Wed, 28 Jul 1999 13:17:55 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id QAA93827; Wed, 28 Jul 1999 16:17:57 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 28 Jul 1999 16:17:57 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Nate Williams Cc: hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907282008.OAA02877@mt.sri.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 Wed, 28 Jul 1999, Nate Williams wrote: > > > > These were changes that were necessary to make ipfw readable enough that > > I could work with it in this area. They aren't just to clean it up, or > > just for change's sake. They need to stay in. > > C'mon now, re-ording the lines is *certainly* not necessary to work. That's true. I sure didn't do that. > > *rant on* > Brian, FreeBSD isn't your private playground for playing around, this is > a group project, and you gotta follow the rules, or you don't get to > play with the rest of the folks.... The rules don't say "leave the code that you work with in a bigger mess than when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be done to get work done, very often. You have to learn to deal with that. > *rant off* > > > > > Nate > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 13:24:30 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id E6A7114D42; Wed, 28 Jul 1999 13:24:26 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id OAA05134; Wed, 28 Jul 1999 14:24:25 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA03102; Wed, 28 Jul 1999 14:24:24 -0600 Date: Wed, 28 Jul 1999 14:24:24 -0600 Message-Id: <199907282024.OAA03102@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Brian F. Feldman" Cc: Nate Williams , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: References: <199907282008.OAA02877@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > These were changes that were necessary to make ipfw readable enough that > > > I could work with it in this area. They aren't just to clean it up, or > > > just for change's sake. They need to stay in. > > > > C'mon now, re-ording the lines is *certainly* not necessary to work. > > That's true. I sure didn't do that. Sure looks like you did. There are white-space and re-ordering modifications in the diffs you sent out. If you didn't do them, who did? > > *rant on* > > Brian, FreeBSD isn't your private playground for playing around, this is > > a group project, and you gotta follow the rules, or you don't get to > > play with the rest of the folks.... > > The rules don't say "leave the code that you work with in a bigger mess than > when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be > done to get work done, very often. You have to learn to deal with that. No, cleanups occur *separately* from code additions. The code is *very* readable now, and just because you have stylistic differences doesn't mean you get to change them because you like them. In particular, the changes I pointed out are not 'cleanups', but style changes. I repeat, this isn't your personal playground. Play by the rules or don't play at all. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 13:33: 9 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id 2E16714C3C; Wed, 28 Jul 1999 13:32:53 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id QAA14034; Wed, 28 Jul 1999 16:32:59 -0400 (EDT) Date: Wed, 28 Jul 1999 16:32:58 -0400 (EDT) From: Alfred Perlstein Reply-To: Alfred Perlstein To: "Brian F. Feldman" Cc: Nate Williams , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: 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 Wed, 28 Jul 1999, Brian F. Feldman wrote: > On Wed, 28 Jul 1999, Nate Williams wrote: > > > > > > These were changes that were necessary to make ipfw readable enough that > > > I could work with it in this area. They aren't just to clean it up, or > > > just for change's sake. They need to stay in. > > > > C'mon now, re-ording the lines is *certainly* not necessary to work. > > That's true. I sure didn't do that. > > > > > *rant on* > > Brian, FreeBSD isn't your private playground for playing around, this is > > a group project, and you gotta follow the rules, or you don't get to > > play with the rest of the folks.... > > The rules don't say "leave the code that you work with in a bigger mess than > when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be > done to get work done, very often. You have to learn to deal with that. > > > *rant off* and so it should remain, changes that provide readability to code should be committed, the only time documentation of code is wrong is when it it is incorrect. Increasing the size of the cvs repo is not a consideration when worthwhile docs can be incorperated, especially when the person who needs to maintain it requires changess for readability. Is there a point to hindering the maintainer's ongoing work? -Alfred Perlstein - [bright@rush.net|bright@wintelcom.net] systems administrator and programmer Wintelcom - http://www.wintelcom.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 13:41:12 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 2E2A014C38; Wed, 28 Jul 1999 13:41:05 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id QAA94340; Wed, 28 Jul 1999 16:39:30 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 28 Jul 1999 16:39:29 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Nate Williams Cc: hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907282024.OAA03102@mt.sri.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 Wed, 28 Jul 1999, Nate Williams wrote: > > > > These were changes that were necessary to make ipfw readable enough that > > > > I could work with it in this area. They aren't just to clean it up, or > > > > just for change's sake. They need to stay in. > > > > > > C'mon now, re-ording the lines is *certainly* not necessary to work. > > > > That's true. I sure didn't do that. > > Sure looks like you did. There are white-space and re-ordering > modifications in the diffs you sent out. If you didn't do them, who > did? I refuse to justify putting variables in a function I changed in the right place. > > > > *rant on* > > > Brian, FreeBSD isn't your private playground for playing around, this is > > > a group project, and you gotta follow the rules, or you don't get to > > > play with the rest of the folks.... > > > > The rules don't say "leave the code that you work with in a bigger mess than > > when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be > > done to get work done, very often. You have to learn to deal with that. > > No, cleanups occur *separately* from code additions. The code is *very* > readable now, and just because you have stylistic differences doesn't > mean you get to change them because you like them. Stylistic differences my ass. This module (ip_fw) breaks style(9) in so many ways, it's not funny. It's sad. > > In particular, the changes I pointed out are not 'cleanups', but style > changes. When you make code readable, it's a cleanup. > > I repeat, this isn't your personal playground. Play by the rules or > don't play at all. "Follow KNF or stay out of the kernel code." > > > Nate > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 13:41:14 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id D912C14C56; Wed, 28 Jul 1999 13:41:08 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id OAA05371; Wed, 28 Jul 1999 14:40:20 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA03306; Wed, 28 Jul 1999 14:40:19 -0600 Date: Wed, 28 Jul 1999 14:40:19 -0600 Message-Id: <199907282040.OAA03306@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alfred Perlstein Cc: "Brian F. Feldman" , Nate Williams , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > *rant on* > > > Brian, FreeBSD isn't your private playground for playing around, this is > > > a group project, and you gotta follow the rules, or you don't get to > > > play with the rest of the folks.... > > > > The rules don't say "leave the code that you work with in a bigger mess than > > when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be > > done to get work done, very often. You have to learn to deal with that. > > > > > *rant off* > > and so it should remain, changes that provide readability to > code should be committed, the only time documentation of code > is wrong is when it it is incorrect. The changes pointed out do *NOT* make the code more readable. They just move statements around for no reason, and change whitespace. > Increasing the size of the cvs repo is not a consideration when > worthwhile docs can be incorperated, especially when the person > who needs to maintain it requires changess for readability. Brian is *NOT* the maintainer, he is the author of a patch to it. Doesn't anyone care for keeping the source code consistant *AND* maintainable for multiple people, as well as maintaining a history of *CHANGES* for people to review in the future? Or is this Linux, where we don't give a rip and whatever the current patch does to the rest of the tree is fine, since the more code we have the better? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 13:43:24 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 9E4D414C56; Wed, 28 Jul 1999 13:43:20 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id OAA05403; Wed, 28 Jul 1999 14:42:35 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA03370; Wed, 28 Jul 1999 14:42:35 -0600 Date: Wed, 28 Jul 1999 14:42:35 -0600 Message-Id: <199907282042.OAA03370@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Brian F. Feldman" Cc: Nate Williams , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: References: <199907282024.OAA03102@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > > These were changes that were necessary to make ipfw readable enough that > > > > > I could work with it in this area. They aren't just to clean it up, or > > > > > just for change's sake. They need to stay in. > > > > > > > > C'mon now, re-ording the lines is *certainly* not necessary to work. > > > > > > That's true. I sure didn't do that. > > > > Sure looks like you did. There are white-space and re-ordering > > modifications in the diffs you sent out. If you didn't do them, who > > did? > > I refuse to justify putting variables in a function I changed in the > right place. This and other obnoxious responses to valid responses makes me want to ask for your commit privileges. You obviously don't care what anyone else has done. > > In particular, the changes I pointed out are not 'cleanups', but style > > changes. > > When you make code readable, it's a cleanup. The code is *NO* more readable by you re-ordering lines and changes whitespace. Grow up and quit acting like a child who doesn't wanna follow the rules. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 13:46:58 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 1DEBA14C56; Wed, 28 Jul 1999 13:46:54 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id QAA94554; Wed, 28 Jul 1999 16:46:22 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 28 Jul 1999 16:46:21 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Nate Williams Cc: Alfred Perlstein , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org, bde@FreeBSD.org Subject: Re: securelevel and ipfw zero In-Reply-To: <199907282040.OAA03306@mt.sri.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 Wed, 28 Jul 1999, Nate Williams wrote: > > > > *rant on* > > > > Brian, FreeBSD isn't your private playground for playing around, this is > > > > a group project, and you gotta follow the rules, or you don't get to > > > > play with the rest of the folks.... > > > > > > The rules don't say "leave the code that you work with in a bigger mess than > > > when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be > > > done to get work done, very often. You have to learn to deal with that. > > > > > > > *rant off* > > > > and so it should remain, changes that provide readability to > > code should be committed, the only time documentation of code > > is wrong is when it it is incorrect. > > The changes pointed out do *NOT* make the code more readable. They just > move statements around for no reason, and change whitespace. It makes it more readable if you understand and use KNF instead of try to bastardize everyone else's code. > > > Increasing the size of the cvs repo is not a consideration when > > worthwhile docs can be incorperated, especially when the person > > who needs to maintain it requires changess for readability. > > Brian is *NOT* the maintainer, he is the author of a patch to it. I'm one of the people who actively works on it. Who are you? > > Doesn't anyone care for keeping the source code consistant *AND* > maintainable for multiple people, as well as maintaining a history of > *CHANGES* for people to review in the future? What do you think KNF is about? I'll bring out the big guns now (BDE). > > Or is this Linux, where we don't give a rip and whatever the current > patch does to the rest of the tree is fine, since the more code we have > the better? > You have no idea what you're talking about, WRT FreeBSD. > > > Nate > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 13:59:48 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id 125BE154EF; Wed, 28 Jul 1999 13:59:40 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id RAA16033; Wed, 28 Jul 1999 17:00:25 -0400 (EDT) Date: Wed, 28 Jul 1999 17:00:23 -0400 (EDT) From: Alfred Perlstein To: Nate Williams Cc: "Brian F. Feldman" , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: <199907282042.OAA03370@mt.sri.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 Wed, 28 Jul 1999, Nate Williams wrote: > > > > > > These were changes that were necessary to make ipfw readable enough that > > > > > > I could work with it in this area. They aren't just to clean it up, or > > > > > > just for change's sake. They need to stay in. > > > > > > > > > > C'mon now, re-ording the lines is *certainly* not necessary to work. > > > > > > > > That's true. I sure didn't do that. > > > > > > Sure looks like you did. There are white-space and re-ordering > > > modifications in the diffs you sent out. If you didn't do them, who > > > did? > > > > I refuse to justify putting variables in a function I changed in the > > right place. > > This and other obnoxious responses to valid responses makes me want to > ask for your commit privileges. You obviously don't care what anyone > else has done. > > > > In particular, the changes I pointed out are not 'cleanups', but style > > > changes. > > > > When you make code readable, it's a cleanup. > > The code is *NO* more readable by you re-ordering lines and changes > whitespace. This is so very objective. > > Grow up and quit acting like a child who doesn't wanna follow the rules. quit acting like and old fart that fears change. (*) afaik, Brian is the mainter of ipfw, it should be noted so, so that if his changes break something it comes down on his head. Trust me to say something if that occurs. I'm no big friend of Brian, however changes to correct readability should be welcome especially to the maintainer. -Alfred Perlstein - [bright@rush.net|bright@wintelcom.net] systems administrator and programmer Wintelcom - http://www.wintelcom.net/ (*) if you don't like "old fart" then choose to play the age card with a bit more thought, there are many other commiters that fall under your catagorization. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 14: 8:23 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 440A815509; Wed, 28 Jul 1999 14:08:18 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id PAA05753; Wed, 28 Jul 1999 15:07:50 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id PAA03686; Wed, 28 Jul 1999 15:07:49 -0600 Date: Wed, 28 Jul 1999 15:07:49 -0600 Message-Id: <199907282107.PAA03686@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alfred Perlstein Cc: Nate Williams , "Brian F. Feldman" , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero In-Reply-To: References: <199907282042.OAA03370@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > In particular, the changes I pointed out are not 'cleanups', but style > > > > changes. > > > > > > When you make code readable, it's a cleanup. > > > > The code is *NO* more readable by you re-ordering lines and changes > > whitespace. > > This is so very objective. That's why it considered a 'stylistic' change, and not a functional change. And, that's why stylistic changes are not allowed to be mixed with functional changes. I quote from a recent article involving Brian early last week. ---------------------------------------------------------------------- From: "Jordan K. Hubbard" Subject: Re: cvs commit: src/usr.sbin/inetd builtins.c Date: Fri, 23 Jul 1999 19:25:26 -0700 > > I realize that stack space is not really an issue. Do you think I care > > about the possible savings of a few bytes? The issue is that variables > > should be declared _in_the_proper_places_, so that's where they go in > > my code. And yes, this is my code. I didn't appreciate Sheldon "restyling" > > it, because that makes it harder for /me/ to maintain. > > Having your own private coding style is arguably OK; using it > in other's code is definitely not. Please stick to the coding style > of the module you are editing. Actually, I hadn't even considered that point but Mark's entirely correct. You don't get to pick your own style in the middle of code that someone else has written, you stick to the SAME style even if it's totally style(9) non-conformant and icky in the extreme. .... ---------------------------------------------------------------------- You don't get to change styles even if it's non-conformant. > > Grow up and quit acting like a child who doesn't wanna follow the rules. > > quit acting like and old fart that fears change. (*) Fears change? Not quite. I was willing to write the necessary changes myself if necessary (see previous email on this thread), but I wanted to make sure it was both desirable (beyond one's person POV), as well as it wouldn't negatively effect other users of the system. > afaik, Brian is the mainter of ipfw, it should be noted so, so that > if his changes break something it comes down on his head. Trust > me to say something if that occurs. Brian is *NOT* the maintainer of IPFW, and thinking that is silliness. If you think that, then you're confused. Being the last person to commit something doesn't make you the committer, and even more so committing one change to the code doesn't make you the committer. I've committed two things to it, so I win by default in that case. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 16:24:26 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from smtp13.bellglobal.com (smtp13.bellglobal.com [204.101.251.52]) by hub.freebsd.org (Postfix) with ESMTP id C509814C3C; Wed, 28 Jul 1999 16:24:16 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere (ppp18328.on.bellglobal.com [206.172.130.8]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id TAA02378; Wed, 28 Jul 1999 19:25:49 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id TAA00407; Wed, 28 Jul 1999 19:24:26 -0400 (EDT) (envelope-from tim) Date: Wed, 28 Jul 1999 19:24:25 -0400 From: Tim Vanderhoek To: Nate Williams Cc: "Brian F. Feldman" , hackers@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: securelevel and ipfw zero Message-ID: <19990728192425.C318@mad> References: <199907282024.OAA03102@mt.sri.com> <199907282042.OAA03370@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199907282042.OAA03370@mt.sri.com>; from Nate Williams on Wed, Jul 28, 1999 at 02:42:35PM -0600 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 28, 1999 at 02:42:35PM -0600, Nate Williams wrote: > > The code is *NO* more readable by you re-ordering lines and changes > whitespace. It's white! No, dammit, it's beige! Fuck you, I said it's white! Beige! White! I dunno, I guess for some people the distinction's actually meaningful, but for myself, I was never good with colours. Colours and such aside, I will have to explain the word "politic" to Brian, someday, though. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 16:41:48 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from smtp13.bellglobal.com (smtp13.bellglobal.com [204.101.251.52]) by hub.freebsd.org (Postfix) with ESMTP id F265D15274; Wed, 28 Jul 1999 16:40:10 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere (ppp18328.on.bellglobal.com [206.172.130.8]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id TAA05969; Wed, 28 Jul 1999 19:40:17 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id TAA00451; Wed, 28 Jul 1999 19:38:50 -0400 (EDT) (envelope-from tim) Date: Wed, 28 Jul 1999 19:38:45 -0400 From: Tim Vanderhoek To: Nate Williams Cc: Alfred Perlstein , "Brian F. Feldman" , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero Message-ID: <19990728193845.D318@mad> References: <199907282040.OAA03306@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199907282040.OAA03306@mt.sri.com>; from Nate Williams on Wed, Jul 28, 1999 at 02:40:19PM -0600 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 28, 1999 at 02:40:19PM -0600, Nate Williams wrote: > > Or is this Linux, where we don't give a rip and whatever the current > patch does to the rest of the tree is fine, since the more code we have > the better? Nate, you know damn well that's not true. You're complaining about three lines in a large patch. Further, those three lines of the patch fix excessively long (+80 char) lines. Yes, you're right that those are non-functional changes and that ideally non-functional changes are placed in separate commits. You've also been around long enough to know that you're right and to be able to say so with an air of authority without a sense of insecurity, ending any debate about it after a mere 2 or 3 curt exchanges. Further, your communication skills should be sufficiently advanced to have noticed what appears (to me, at least) to have been the subtle miscommunication that occurred between message-id <199907282000.OAA02728@mt.sri.com> and message-id which lead to the stupid place you two are now sitting in. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 16:51:35 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C9BC914F9C; Wed, 28 Jul 1999 16:51:24 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA64420; Wed, 28 Jul 1999 16:48:43 -0700 (PDT) (envelope-from dillon) Date: Wed, 28 Jul 1999 16:48:43 -0700 (PDT) From: Matthew Dillon Message-Id: <199907282348.QAA64420@apollo.backplane.com> To: Tim Vanderhoek Cc: Nate Williams , "Brian F. Feldman" , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero References: <199907282024.OAA03102@mt.sri.com> <199907282042.OAA03370@mt.sri.com> <19990728192425.C318@mad> Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> The code is *NO* more readable by you re-ordering lines and changes :> whitespace. :... :.... :..... Sounds like one of many arguments I've had with various people who insist on nitpicking and critiqing to death tiny little itsy bitsy inconsistancies that no normal person would care about, in a commit that may have taken the author hours of work to make happen. Gee, someone getting a little hot under the collar? Why am I not surprised. It's one thing when the style's clash badly, quite another when the differences are minor -- things like blank lines (or lack of). I'll tell you something, folks, we don't need that kind of aggravation when the style differences are minor. If people want to insist on nitpicking the code, I recommend a rules change: Such people have to wait a month first, and then offer to make the style fix FOR the author rather then badger the author of the patch to do it. After all, the author of the patch is simply trying to fix the code, and spending a considerable amount of his own time doing so. The nitpicker, on the otherhand, is acting like a spoiled brat who can't be bothered to make the change himself after asking for (and almost certainly getting) permission. After a month, when the code in question is less likely to be under active development and the patch won't mess up the developers own tracking of the work, the nitpicker can offer to make the style commit. That strikes me as being quite fair. I also take exception to people trying to use KNF as a defense for their nitpicking. KNF is all well and fine, but it is not possible to lock any style in stone for years and years. You don't get new blood into a project that way, and only the few originals left in the crew wind up being comfortable with it. For example, take the evolution of procedural prototypes. When procedures were initially prototyped a lot of work went into the __P() style to allow compilation with and without prototypes. But in the last few years a significant portion of the code no longer bothers with __P() --- because the code is *expected* to be prototyped and *expected* to be compiled with a compiler that understands them. I am sick and tired of standards which are unable to evolve with the times and I am sick and tired of people who try to enforce standards yet are unwilling to allow them to evolve in any meaningful fashion. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 28 17:56:49 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 2EABA1529E; Wed, 28 Jul 1999 17:56:37 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA65104; Wed, 28 Jul 1999 17:55:58 -0700 (PDT) (envelope-from dillon) Date: Wed, 28 Jul 1999 17:55:58 -0700 (PDT) From: Matthew Dillon Message-Id: <199907290055.RAA65104@apollo.backplane.com> To: "Brian F. Feldman" Cc: Nate Williams , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero References: Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Wed, 28 Jul 1999, Nate Williams wrote: :> > :> > These were changes that were necessary to make ipfw readable enough that :> > I could work with it in this area. They aren't just to clean it up, or :> > just for change's sake. They need to stay in. :> :> C'mon now, re-ording the lines is *certainly* not necessary to work. : :That's true. I sure didn't do that. : :> :> *rant on* :> Brian, FreeBSD isn't your private playground for playing around, this is :> a group project, and you gotta follow the rules, or you don't get to :> play with the rest of the folks.... : :The rules don't say "leave the code that you work with in a bigger mess than :when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be :done to get work done, very often. You have to learn to deal with that. : :> *rant off* :> :> Nate :> : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ : green@FreeBSD.org _ __ ___ | _ ) __| \ Side note: I do the same thing: clean up certain portions of the code in order to make them more readable while I'm working on the module. And while I tend to agree that it would be nice to commit the bug fixes separately, it just isn't practical most of the time because one might have already spent too big a chunk of one's own time to do the work in the first place. And I get the same sort of crap from certain core members, too. It's truely annoying when you've spent the time ( sometimes a whole LOT of time ) and trouble to fix something and all some people can do is complain about extremely trivial elements of the work. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Jul 29 1:27:57 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from gemini.bnc.net (gemini.bnc.net [195.247.233.33]) by hub.freebsd.org (Postfix) with ESMTP id 1D9A215034; Thu, 29 Jul 1999 01:27:43 -0700 (PDT) (envelope-from ap@bnc.net) Received: (from ap@localhost) by gemini.bnc.net (8.9.3/8.9.3) id KAA80825; Thu, 29 Jul 1999 10:27:30 +0200 (CEST) (envelope-from ap) Date: Thu, 29 Jul 1999 10:27:30 +0200 From: Achim Patzner To: "Brian F. Feldman" Cc: Nate Williams , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero Message-ID: <19990729102730.B75233@bnc.net> References: <199907282008.OAA02877@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Brian F. Feldman on Wed, Jul 28, 1999 at 04:17:57PM -0400 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 28, 1999 at 04:17:57PM -0400, Brian F. Feldman wrote: > > Brian, FreeBSD isn't your private playground for playing around, this is > > a group project, and you gotta follow the rules, or you don't get to > > play with the rest of the folks.... > > The rules don't say "leave the code that you work with in a bigger mess than > when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be > done to get work done, very often. You have to learn to deal with that. I don't see _removing_ white space improving readability (but I started out as a programmer working for a company where reviewers had to check if at least 40% of the sources were _meaningfull_ comments, all closing } had a comment telling what the block was good for and where goto and break (except in case statements) were completely forbidden). If you two can't settle your arguments you might send the patches to the Bruce-machine... Achim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Jul 29 19:21:56 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 30EE914F44 for ; Thu, 29 Jul 1999 19:21:45 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id WAA00564 for ; Thu, 29 Jul 1999 22:21:16 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Thu, 29 Jul 1999 22:21:16 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: freebsd-ipfw@FreeBSD.org Subject: IPFW logging changes done 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 If noone has any objections, I'd like to commit these if there are no good objections. My changes address concerns with logging abilities not being dynamic enough and not having an ability to reset logging, especially at a high securelevel. They are posted at http://www.FreeBSD.org/~green/ipfw.patch, and should be in their final incarnation. Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message