Administrative logging service for Samba

[David Collier-Brown]

Caleb Jorden schrieb:
>>I am interested in implementing an administrative logging service for 
>>samba.  This functionality would be similar to the debug logs, but would 
>>contain activities which a system administrator would be interested in 
>>knowing.  For example, especially when samba is a domain controller, it is 
>>imperative that the administrator know when an attack is occurring on his 
>>or her domain.  
[...]
>>4. The information could be tagged with both an eventTypeID and an eventID
>>        - Example: ADMINLOG(ADMINLOG_SECURITY, 
>>ADMINLOG_SECURITY_ACCOUNT_LOCKOUT,
>>                                "Account %s was administratively locked 
>>out\n", username);

Stefan (metze) Metzmacher wrote:
>>I prefer option 4, because it would allow for specific types of logging 
>>events to be filtered by a configuration option in smb.conf, and would 
>>allow for specific searches and sorting of result.

	This is a commonly reinvented wheel, and the version you
	suggested in (4) is the round one (;-))

	A maximally useful log message contains a number of fixed
	items, usually in a fixed-format header of some sort, and
	text for the human reader to use to understand the implications
	of the problem.

	From memory, the fixed information includes enough to allow
	for mechanical sorting by nastiness and occasionally mechanical
	processing:

	- date/time
	- origin, meaning machine- or domain-name
	- source, in some detail,, including the executable name
		and process id as a minimum, if applicable,
		and optionally the file, function and line, 
		it is good to make this one token, for ease of
		parsing and resilience when one line has
		"sendmail:parse.c:parse_it:332:1948" and another has
		only "mconnect:1293"
	- pre-classification, meaning the application type, error type 
		and severity. DFAs can switch on this, and should.
		The old ARPA format was <error type> <source> <severity>
		as three decimal digits, which you still see when
		smtp says "250 ok". The 2 was permanent success, the 5
		meant "the app", in this case smtp, and 0 was the severity.
		I prefer ascii, not numbers (;-))
	- then the text for the human, saying the meaning of the error,
		the same way you're supposed to write the **meaning**
		of code in comments, not just say what the code does.
	
	Syslog does about half of this,	yours does most:
	for example
 ADMINLOG		-- implies origin and source
    (ADMINLOG_SECURITY, -- preclassification, app type
     ADMINLOG_SECURITY_ACCOUNT_LOCKOUT, -- preclass, error type
     "Account %s was administratively locked" -- message for human

	I'd suggest saying which account, and optionally a severity,
	such as {for 3 minutes, for a day, until overridden, permanent}
	such as
ADMINLOG(ADMINLOG_SECURITY,ADMINLOG_SECURITY_ACCOUNT_LOCKOUT,REPEATED_LOGIN_ATTEMPTS,
	"Account %s login failed more than 3 times, locked for 1 day", user);
	
	which would be selected via the fixed header into a processing	
	script for just timed lockouts, sorted on user, counted and reported 
	whenever a user was locked more than N times in a fixed period

--dave
-- 
David Collier-Brown,      | Always do right. This will gratify
Sun Microsystems, Toronto | some people and astonish the rest
davecb at canada.sun.com     |                      -- Mark Twain
(416) 263-5733 (x65733)   |