Re: finger-bombing

[chowes () helix net (Charles Howes)]

On Thu, 13 Oct 1994, James Seng wrote:

> On Wed, 12 Oct 1994, Christopher Klaus wrote:
> > Contact the admins of those hosts and tell them to have it stopped.  
> > Also, modify inetd.conf and comment out finger and kill -HUP inetd
> > to restart it.
>
> A question which is not really relvant to this mailing-list..What if the 
> admin is the one who is guilty of such attack? (attack here refers to 
> more general case than just fingering) Who do i inform or do i have to 
> deal it myself? :-)

Fortunately, there is always a course of action.

For any site, if you can't get satisfaction, you can go up the chain of
command until you *do* get satisfaction.

Universities, companies, and others are on the net for a reason, and
usually want to be good neighbours.  University and company presidents
are usually quite responsive if their subordinates are causing
problems.

And, if the president is causing a problem, there's a network provider
that can always be approached.

If *that* fails to satisfy you, you can either take it to usenet, or
decide you were wrong.  Sometimes both.  :-)


As to the original question, would creating a fifo called .plan be
good or bad?  It would freeze finger requests as they were made,
allowing a more casual tracing, but risks overflowing some kernel
table?

Also, if it is being done indirectly (finger user@yourhost@host1), ask
the folks at host1 if they could keep logs of finger requests, as well
as put in the ident service.  (Tcp wrappers, pidentd and syslog.)


ObBug: the C2conv program on SunOS 4.1.3 seemed to have dumped garbage
  over part of our password file when we tried it the other day.  The
  syslog for auth.info exploded as a result.  It's almost as secure as
  dumping the computer into wet cement, and takes less time.  How *do*
  you set up shadow passwords, anyway?

ObBug2: I was talk-bombed the other day.  You can modify a talk
  program to send escape sequences in the talk request, messing up the
  recipient's screen.  Since it's UDP, finding the culprit is not
  possible with tcpd.  Anyone have a solution?

--
Charles Howes -- chowes () helix net
 Always tell the truth, then you make it the other bloke's problem! 
 - Sean Connery, 1971