On Mon, 1 Nov 1999 [EMAIL PROTECTED] wrote: > This is supposed to be a full-fleged secure, robust replacement for syslog > in modern environments where neither network nor CPU bandwidth, nor disk > storage, is at a premium. <snip> We're definitely moving towards bigger stuff all the time, yes. However, I dont - personally - see that as good reason to make something bloated without much of a gain easyness of implementation. On a less personal level, I have.. lets say, a couple, 128Kbit pipes. These pipes are pretty loaded by the application (dedicated system) as is. A slick system could coexist with the other stuff on the pipes. A hog system cant. As for the cost of these pipes, it's definitely enough to pay for a daycare center or somesuch. Sens morale? Your bandwidth mightnt be worth anything. Mine is, hence, it's in my interest to remind people that yes, in the real world, stuff costs. <snip> > applications. If you invent your own encoding, you will have to do > your own parsers; because coding errors in such things are the most > vulnerable feature of existing protocol implementations (esp. syslogd) > reusing documented, well-exercised code is an important security > feature. Cant really see how that would be a -security- feature. Yes, some standardization help, not arguing there, but making something XML doesnt neccessarily make people less prone to stupidities. Ymmv, of course.. <snip> > Again, it's a wire transport encoding, intended for high-security and > high-functionality logging systems, probably over TCP. The receiver at the > log server daemon can save the records in XML as received, or encode into > some more compact form for storage economy, or some more verbose form (if > necessary) for readability, filtering, and presentation. That's the set of > issues discussed in the ULM draft. Again, it's the stuff it sends down the wire that is my concern here. If you can 'force' something to send five, ten, maybe twenty times the data you use to trigger the log entry, you're a good way closer to denial of service. It may be high this, high that, high everything - if it makes something vulnerable from normal usage (logging selective IP traffic could very well be considered normal usage, imo), it's an achilles heel. Of course, I might be barking up the wrong tree myself thinking it's better do use standard stuff than specialities in order to keep stuff running in a somewhat secure way. Am I? Kriss Andsten --- .... --..-- -.-- --- ..- .-. . .- -.. -- --- .-. ... . --..-- . .... ..--.. Kriss Andsten <[EMAIL PROTECTED]> telnet slartibartfast.vogon.se 4243
