keystroke logging

[richard childers / kg6hac]

I did say 'modified' script(1), yes, the obvious has been taken into 
account.

Thanks for pointing it out, though !!

-- richard


Peter Pentchev wrote:

>On Wed, Jan 07, 2004 at 08:15:16PM -0800, richard childers / kg6hac wrote:
>  
>
>>>What do you recommend for keeping track of user
>>>activities?  For preserving bash histories I followed
>>>these recommendations:
>>>
>>>http://www.defcon1.org/secure-command.html
>>>
>>>      
>>>
>>Interesting reading but, as others have noted, of limited use.
>>
>>Keystroke logging can be disabled by - as others have noted - either 
>>spawning another (perhaps different) shell, using a remote shell ... or, 
>>for those embarrassing 'oops' moments, `kill -9 $$` works nicely. Try it 
>>and see.
>>
>>Daemonized Networking Services has produced a standalone server 
>>configuration that uses a modified script(1) and .login to collect 
>>keystroke logs; the target users are consultants, or companies, whom 
>>administer highly secure networking equipment via serial links or 
>>command-line interfaces, and whose own business files, or customers - 
>>banks, say, or government agencies - require logs of what they did - for 
>>purposes of auditing, disaster recovery, and liability-related issues.
>>
>>This method captures every keystroke - including typos before hitting 
>>RETURN - and cannot be sabotaged. As an added advantage, the logs can be 
>>immediately, or subsequently, forwarded via electronic mail, so that 
>>they are replicated in multiple places.
>>    
>>
>
>I hope you've taken into consideration the fact that script(1) by
>default does not make any modifications to stdio's standard input/output
>buffering.  Thus, the script files it creates are fully-buffered by
>default, which for normal files means that they are only actually
>written to when the buffer fills up, and the buffer is usually 1K to 8K
>in size (although I've seen systems with a BUFSIZ of 32K).  This means
>that if anyone kills the script(1) process before the output has reached
>1K (or 4K, or whatever) in size, *no* output will be logged, and even if
>the script process is killed afterwards, some of the output will be
>lost.  Consider:
>
>[roam at straylight ~]> echo $$
>5781
>[roam at straylight ~]> script outfile
>Script started, output file is outfile
>Starting interactive C shell
>[roam at straylight ~]> echo $$
>5914
>[roam at straylight ~]> ps -o ppid -p $$
> PPID
> 5913
>[roam at straylight ~]> kill -HUP 5913Hangup
>                                         [roam at straylight ~]> echo $$
>5781
>[roam at straylight ~]> cat outfile
>Script started on Thu Jan  8 09:20:17 2004
>[roam at straylight ~]>
>
>The -t option is of some help, although -t 0 could be implemented a bit
>more efficiently with the attached patch.
>
>G'luck,
>Peter
>
>  
>

-- 

Richard Childers / Senior Engineer
Daemonized Networking Services
945 Taraval Street, #105
San Francisco, CA 94116 USA
[011.]1.415.759.5571
https://www.daemonized.com