Date: Tue, 27 Jul 1999 13:56:55 -0500 (CDT) From: Joe Greco <jgreco@ns.sol.net> To: nate@mt.sri.com (Nate Williams) Cc: hackers@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: securelevel and ipfw zero Message-ID: <199907271856.NAA09504@aurora.sol.net> In-Reply-To: <199907271652.KAA25747@mt.sri.com> from Nate Williams at "Jul 27, 1999 10:52:22 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907271856.NAA09504>