From: 00bestrawser@bsu-ucs.uucp (Bryan Strawser)
Newsgroups: comp.admin.policy
Subject: Re: Privacy vs. Security concerns: Should excessive i
Date: 6 Apr 92 19:52:20 GMT

In article <2APR199219194791@moose.cccs.umn.edu>, rao@moose.cccs.umn.edu (Rao V. Akella) writes:
> 
> Should you try to trace someone who's showing an excessive interest in your
> site?  Especially if it looks like a case of conflict between privacy and
> security concerns?
> 

	Umm..  that would depend on your particular case, but read on...

> I recently started logging every tcp/ip connection attempt to my system
> (finger, ftp, talk, telnet...you get the picture).  A typical finger log looks
> like this one below:
> 
> 31-MAR-1992 21:20:16 FINGER (accepted) from [128.101.133.53,1044]
> 						(moose.cccs.umn.edu)
> 

	I, too, log every tcp/ip connection into our VaxStation 3100 which
	I co-manage with my boss.  And I've followed up on a few cases like
	this, when there are lots of things from a remote site...  But never
	to the point of writing to a remote site.. :)


> This revealed the rather interesting fact that someone at a remote site (not
> the one above -- that's me!) is fingering my system a large number of times
> every day (typically a couple of dozen attempts every day).  It's like living
> under constant surveillance.  As you can see, the log doesn't record the remote
> username, only the originating site, and it doesn't say which local user is
> being queried (I gather this is a limitation of the finger protocol, and can't
> be helped, though I suppose I could put ACL alarms on all .plan files for my
> local users who have them).
> 

	That is rather interesting, since Multinet's finger shows the
	current image as part of its output.. 

	Then again, there are some remote sites that I finger a few times 
	every once in a while, mostly to read people's plan files.. they
	tend to be funny :)

> The question is, what should we do -- or, to be precise, how far should we go
> in trying to track this person down?  My manager is itching to fire off a nasty
> note to postmaster@remote.site telling them to trace this user and keep him or
> her out of our hair, since it's "obvious" that this person is up to no good. 
> I, however, took the viewpoint that since we're offering finger as a free, open
> and helpful service, we should act like we aren't even keeping any logs and we
> don't know about this user's interest in us (my reasoning being, since
> fingering is legal, it doesn't matter how many times you do it).
> 
> I would be interested in Comments From Cyberspace.  What would YOU do in a case
> like this?  It would be a simple matter to configure my finger daemon to reject
> all requests from the node in question, but, in the interest of maintaining a
> free and open system, I would rather not take this approach.  So far, my
> idealistic stance has won out and we're ignoring this person (except that I'm
> keeping a closer eye than usual on my security audit and intrusion alarms).  On
> the other hand, my sensible and rational side keeps urging me: "To be fore-
> warned is to be forarmed!  Find out what this user is up to.  At least do a
> reverse finger on the remote system.  Better safe now than sorry later!"
> 

	That's pretty close to what I did..  I told finger to reject ftp/finger
	requests from that site for a while.. but that was when there were
	other odd things going on, and I just wanted to make sure that this
	incident was not related..

> I suppose I should consider myself fortunate that my logs don't reveal which
> local user is being fingered, otherwise I would have been confronted with the
> equally delicate dilemma as to whether I should inform the user that someone at
> another site is keeping tabs on them.

	Hehe..  that's true..  I wish we could finger out that info :)


-- 
Bryan Strawser			   |	  		Ball State University
University Computing Services	   |			     Muncie, IN 47306
bryan%marvin@leo.bsuvc.bsu.edu     |		         Student / Programmer
00bestrawser@leo.bsuvc.bsu.edu     |			 00bestrawser@bsuvax1
Newsgroups: comp.admin.policy,alt.comp.acad-freedom.talk