Path: utzoo!mnetor!uunet!mcvax!ukc!mupsy!liv-cs!sqkeith
From: sqkeith@csvax.liv.ac.uk
Newsgroups: comp.os.vms
Subject: Re: DECnet X.29 error messages
Message-ID: <402@csvax.liv.ac.uk>
Date: 19 Feb 88 09:32:49 GMT
References: <675*kenw@noah.arc.cdn>
Lines: 31
Organisation: Computer Science CSVAX (VAX1), Liverpool University


In article <675*kenw@noah.arc.cdn>, kenw@noah.arc.CDN (Ken Wallewein) writes:
> 
>   Every so often I met OPCOM messages like:
> 
>> %%%%%%%%%%%  OPCOM   8-FEB-1988 08:57:19.60  %%%%%%%%%%%
>> Message from user DECNET
>> DECnet event 7.10, call failure
>> From node 1.27 (CALARC),  8-FEB-1988 08:57:19.53
>> Module X25-PROTOCOL, DTE = xxxxxxxx, Network = DATAPAC
>> Direction = Outgoing, Call failure = Remote DTE cleared
>> Remote DTE = xxxxxxxx
> 
>   Now, I know how to turn these messages off, and all that. What I _really_
> want to know is WHICH (*^@$_*(&@# PROCESS IS RESPONSIBLE FOR ORIGINATING THE
> CALL!?!?!?  I mean, _somebody_ is trying, knowingly or otherwise, to connect
> to the remote DTE. The question is, who? 
> 

Set an alarm journal (success and failed access) on SYS$SYSTEM:PSIPAD.EXE then
switch on the security facility with something like: 

SET AUDIT/ALARM/ENABLE=ACL

Via OPCOM, every time someone accesses PSIPAD.EXE you will see a message
stating who, when, what-with(privs) etc... Because the above DECnet event
will follow pretty quickly after accessing PSIPAD, the two messages should
not be too far away in the operator's log.

Hope this helps,

Keith Halewood