freebsd security - Jan 2004 - keystroke logging

>
>
>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.

We also have a network server configuration that incorporates everything 
described above, as well as an encrypted filesystem; although the 
encrypted filesystem is optional, and there are some unresolved issues 
related to backing up the contents - as well as recovering them - your 
entire home directory, including your personal startup files, are 
incorporated into the encrypted filesystem. Pretty cool; add a GUI, 
maybe an office suite, and we think we can give Windows 2000 a run for 
their money - in some quarters, at least. (Angel VCs are welcome; 
development isn't cheap, here in the Bay Area.)

I mention this as a shameless plug for our products, which are based on 
FreeBSD, as well as pursuant to the topic at hand; incidentally, freely 
dispensing intellectual property that took years to acquire, in 
exchange. (Gotta stop that.)

(You folks all signed NDAs, right?)

(-;


Regards,

-- richard

-- 

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

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@straylight ~]> echo $$
5781
[roam@straylight ~]> script outfile
Script started, output file is outfile
Starting interactive C shell
[roam@straylight ~]> echo $$
5914
[roam@straylight ~]> ps -o ppid -p $$
 PPID
 5913
[roam@straylight ~]> kill -HUP 5913Hangup
                                         [roam@straylight ~]> echo $$
5781
[roam@straylight ~]> cat outfile
Script started on Thu Jan  8 09:20:17 2004
[roam@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

-- 
Peter Pentchev	roam@ringlet.net    roam@sbnd.net    roam@FreeBSD.org
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
This sentence is false.

Index: src/usr.bin/script/script.c
==================================================================RCS file:
/home/ncvs/src/usr.bin/script/script.c,v
retrieving revision 1.20
diff -u -r1.20 script.c
--- src/usr.bin/script/script.c	4 Sep 2002 23:29:06 -0000	1.20
+++ src/usr.bin/script/script.c	8 Jan 2004 07:39:00 -0000
@@ -150,10 +150,12 @@
 	if (child == 0)
 		doshell(argv);
 
-	if (flushtime > 0)
+	if (flushtime > 0) {
 		tvp = &tv;
-	else
+	} else {
+		setvbuf(fscript, NULL, _IONBF, 0);
 		tvp = NULL;
+	}
 
 	start = time(0);
 	FD_ZERO(&rfd);
@@ -187,7 +189,7 @@
 			(void)fwrite(obuf, 1, cc, fscript);
 		}
 		tvec = time(0);
-		if (tvec - start >= flushtime) {
+		if (flushtime > 0 && tvec - start >= flushtime) {
 			fflush(fscript);
 			start = tvec;
 		}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-security/attachments/20040108/3902e0af/attachment.bin