[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: syslog options, OPIE (S/Key) -- When?

> On Mon, 12 May 1997, Jim Dennis wrote:
> [...]
> Knowing the (PID and username and time) or the (PID and terminal and
> time) or the (username and terminal and time) is enough to get you the
> IP address (via wtmp).  Putting an IP address in there implies that
> changing a password is a network opation; it isn't.

	What is the command to extract this information from wtmp?

>>This last requirement gives a hint as to which member of "wheel" issued
>>a change.  That would be a useful -- though not "strong" -- audit issue.
> I like the idea of knowing who changed someone else's password.

	Again -- this is more a matter of administrative convenience.
	I usually set up teams of admins to use sudo to attain a
	root shell -- and make that the standard operating procedure.
	Direct root logins are discouraged at most sites (and 
	impossible at some -- without opening the envelopes and
	combining the components to a escrowed password).
>>(While we're on the topic of syslogging it would also be nice to syslog
>>all 'chmod +s' attempts and successes).
> That would require a change to "chmod", which is outside the pervue of
> PAM.

	Just a side note -- no implication intended.
	The note is that I'd like to see syslog in a number
	of utilities.  I can trim syslogs -- so "too much"
	information isn't a problem (until we start seeing a
	performance hit!).

> [...]
>>What I'd like to do with this log is to use my existing log monitor
>>(just a shell script at this point -- that does a "tail -f" piped into
>>an awk script)...
> If you haven't already done so, you might consider using "swatch"
> (shipped with Red Hat Linux 4.1) to monitor your logs.

	I've been meaning to look at it -- though I have a 
	pretty good filter already written in awk.  It's
	my own custom log rotation scheme -- which I hope to 
	convert to perl and write up for one of my Linux Gazette
	articles -- one of these months.
>>...to mail confirmation/warning messages off to a user any time a change
>>is attempted.
> And notify a successfull hacker that you noticed their attempts?  It would
> probably be a better idea to fire-off a message to your support folks
> and have them call the user directly.

	I fail to see the full line of reasoning here.
	If the cracker is "successful" he will have completed
	a successful passwd change he'll see that something on 
	the system noticed it.  He may guess that a copy (Bcc:
	or separate) has gone to the sysadmin team -- and therefore
	guess that the gig will soon be up.  However -- I don't 
	see how this will change the "successful" cracker's 

	The important point here is that most of these users
	have .forward files or alias entries.  The successful
	cracker may not be able to stop that mail -- particularly
	when the syslog machine is a remote host  (this entails
	keeping the alias file on the syslog host in sync with
	the user list on all clients -- a minor matter of programming).

	In any event -- it doesn't seem to substantially degrade
	the value of these measures (any more than having a klaxon
	ring out when a car is being tampered with).  It is, however,
	a requirement of my customer.  Here I'm looking at the safest
	means to implement it.  I don't want my login shell to be a 
	script (not even a perl script -- which is somewhat more
	resistant to IFS tomfoolery than Bourne) -- and I don't even
	want to make it a C program (wrapper) with calls to 
	passwd and mail.   The mechanism I describe seems to add the
	least amount of code to the base programs -- and offer the
	greatest administrative flexibility.

	The problem with sending every note the the admins is that
	they'll learn to ignore them as "normal" (noise).  I want to
	send them messages about failures (which are more likely to be
	a sign of user confusion than of attempted crackery) and I want
	the change to be noted by the user -- with enough information 
	so they can notify the appropriate security/administrative
	people in the event of suspicious activity on their account.
	(The template includes clear instructions to e-mail AND call
	via voice line -- giving specific addresses, phone and pager
	numbers. It is PGP signed, though many of the users are not
	PGP aware).

Jim Dennis,                                info@mail.starshine.org
Proprietor,                          consulting@mail.starshine.org
Starshine Technical Services              http://www.starshine.org

        PGP  1024/2ABF03B1 Jim Dennis <jim@starshine.org>
        Key fingerprint =  2524E3FEF0922A84  A27BDEDB38EBB95A 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []