Date: Mon, 26 Jul 1999 15:10:45 -0500 (CDT) From: Joe Greco <jgreco@ns.sol.net> To: nate@mt.sri.com (Nate Williams) Cc: jgreco@ns.sol.net, dillon@apollo.backplane.com, hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero Message-ID: <199907262010.PAA13453@aurora.sol.net> In-Reply-To: <199907261944.NAA20897@mt.sri.com> from Nate Williams at "Jul 26, 1999 1:44:16 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > > :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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907262010.PAA13453>