Re: Re[2]: [logs] Logging: World Domination

cadamsat_private

On Thursday, August 22, 2002, at 09:39 , Kyle R. Hofmann wrote:
>> - support for hierarchal data
>
> But the second one isn't.  We need a distinction between data that are
> required for every message, like timestamps, and data that are specific 
> to
> the type of message.  The ability to nest is unimportant, and that is 
> why XML
> is overkill.

Nesting is definitely less of a priority but I think it would be useful 
for having standard tags which could be used in different events to 
refer to things like IP packets or login requests:

<event class="web" type="transaction" status="access denied">
	<auth_request name="joeblow" authtype="ldap" domain="..." 
result="failed" reason="bad password" />
</event>

<event class="smtp" type="transaction" action="relay" 
status="successful">
	<auth_request name="joeblow" authtype="smtp auth" result="success" />
	<from address="foo@bar" host="192.168.1.1" rbl="false" />
	<to address="baaz@quux" mx="192.168.23.24" />
</event>

The idea is just that it would be nice for analysis packages to be able 
to recognize "standard" chunks and use them for basic reporting even if 
they don't have domain-specific knowledge about the event. A monitor 
could tell which services a given user is trying to access even if it 
doesn't know any of the service-specific details.

Another use for nesting is basically a namespace issue. I'd prefer to 
have, say, a standard IDS message and all of the vendor-specific stuff 
in a <$vendor> subtag rather than a bunch of vendor-prefixed tag names.

The other area where nesting feels more natural is dumping more complex 
data - things like RPC calls or SSL negotiation:

<event class="web" type="transaction" status="access denied">
	<user name="joeblow" authtype="ssl" result="failed" 
reason="untrusted chain">
		<x509 encoding="PEM">
			....
		</x509>
	</user>
	...
</event>

> Now, you might rightly point out that this is a dumb scheme which opens 
> up
> the possibility of malformed collections of tags.  But none of the 
> schemes

I'm inclined to say that it's a bad idea to have parts of the same 
message spread over separate messages but you're certainly right that it 
could be done either way.

> And furthermore, we'd prefer to avoid "Message delivered
> successfully" because that's a freeform string, so ideally all the tags
> would be empty.

Presumably we'd define a DTD which would make any tags which could be 
empty on successful transactions optional.

> So let me be productive for a moment and propose an alternate solution: 
> Syslog
> messages will be single lines of whitespace delimited text.  They will 
> be
> divided into two parts, a universal part which every message will have, 
> and
> a variable part which will vary depending upon the type of the message.

This approach would definitely work for the smaller stuff. I'm not sure 
whether we want the larger, more detailed messages in syslog - I like it 
from a debugging standpoint but it does increase the amount of data 
we're shoving around considerably.

Chris

_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
https://lists.shmoo.com/mailman/listinfo/loganalysis