kenw@noah.arc.CDN (Ken Wallewein) (02/08/88)
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? Does anybody have a solution? /kenw
sqkeith@csvax.liv.ac.uk (02/19/88)
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