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