We want to correct that by writing a small program that will be called
early in the sylogin.com of the system and create an audit entry (there
is a system call to do that) with the name of the real user. Not
difficult.
The problem is to decide whether or not to run the program. It is
useless to do it when telnet is used to enter the system, since in
this case a proper audit record has already been created by OpenVMS
itself. It is only when SSH is used to come in that the program must
run. But how can I detect, with some DCL code, that the SSH protocol
has been used rather than another one ? Any idea ?
Thanks in advance,
--
Marc Van Dyck
See the following:
http://labs.hoffmanlabs.com/node/1224
in which he says:
"Examples of template devices include LTA0: for LAT, and
NTA0: and TNA0: for telnet devices. Both DECnet and ssh
tend to use FTA0:."
So if you can find the correct pid for your current login,
then use f$getjpi for item TERMINAL or TT_ACCPORNAM, you
can at least narrow it down to either DECnet or ssh by looking
for FTA in the string.
I'm not sure how to rule out DECnet.
--
Dale Dellutri <ddelQ...@panQQQix.com> (lose the Q's)
This may depend on the version of VMS, but how 'bout this:
$ term = f$trnlnm("TT") ! gives you _FTA0: or _TNA0: or OPA0: or ...
$ term = term - "_" ! lose the underscore
$ if f$ext(0,2,term).eqs."FT" ! it's either DECwindows or SSH
$ then
$ if f$trnlnm("SYS$REM_ID").nes."" ! it must be SSH
$ then
$ ! do your SSH stuff here...
$ endif
$ endif
/Wilm
SSH under TCPIP Services I presume?
Look in the JOB logical table. If the terminal is a pseudo-terminal
and the JOB table logicals look like:
"SYS$REM_ID" = "SSH_13579BDF"
"SYS$REM_NODE" = "remotehostname.remotedomainname.tld::"
"SYS$REM_NODE_FULLNAME" = "remotehostname.remotedomainname.tld::"
I would say you might just have an SSH login.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
http://www.quirkfactory.com/popart/asskey/eqn2.png
"Well my son, life is like a beanstalk, isn't it?"
DECnet terminals (SET HOST) use RTAn:
/Wilm
OK, will try that at work tomorrow morning. Many thanks to all who
responded !
--
Marc Van Dyck
--
Marc Van Dyck
FTAs do not, by default, employ TT_ACCPORNAM.
Marc,
I may be old-fashioned, but I would definitely report it. There are at
least two reasons for this recommedation.
- It appears to be incorrect, and it will never get fixed if it is not
reported.
- A bug report and a case number are a good answer for the inevitable
auditor question: Why did you do this? In this case, the answer is: We
reported the bug, and implemented a workaround until the problem is
corrected.
- Bob Gezelter, http://www.rlgsc.com
Nice answer. I have a meeting with my HP account team tomorrow morning,
I will ask them to open a case. That being said, I have never been too
impressed with the OpenVMS knowledge of the auditors I have met so far.
They only know Linux and Windows. If it continues like that, I do not
expect to ever have to answer that kind of question.
--
Marc Van Dyck
looking for a FTAnnnn: terminal type *might*
be sufficient for your purposes.
$ tty = "''f$trnlnm( "SYS$OUTPUT" )'"
$ tty = "''f$getdvi( tty ,"TT_PHYDEVNAM" )'"
$ loc = f$locate( "_FTA" ,tty )
$ not_fta = (loc .ge. len)
$ if( not_fta )
$ then
$! ...
"Marc Van Dyck" <marc.v...@brutele.be> wrote in message
news:mn.d4c17d9a41...@brutele.be...
> We are running a banking environment where high-level traceability
> is required. For OpenVMS systems, audit is the key to that. It is
> mostly ok, but we have discovered a serious flaw : when a user logs
> into an OpenVMS system using SSH (as we are all required to do, since
> telnet is considered unsecure),
If you are using Multinet with IPsec then Telnet (or FTP or ODBC or
any-Socket) away to your heart's content *securely*. With TCP/IP services it
will be around another 6 months for 8.4 but those who want to herd you into
their little empire will be sand-bagging the release of a supported IPsec
for a further 6 months.
> --
> Marc Van Dyck
>
Cheers Richard Maher
>
You can probably create and install your fix in one millionth of the
time the HP would require to create and publish one.
Yes HP should and probably will fix it. Just don't hold your breath!
I have done it by checking doing a f$getdvi(term,"TT_SECURE"), which was not set for Decnet FTA processes but was for SSH FTA processes.
Cheers,
Chris
You don't say which TCP/IP implementation you use.
We use Multinet 5.0 and in our SYLOGIN.COM the check looks like:
$ SSH_LOGIN = f$trnlnm("SYS$REM_NODE") .eqs. "SSH::"
TT_SECURE (Secure server) had a completely different meaning when
using hardwired terms. However, it does appear to be set when the
FTA was created as part of the SSH session.
I checked a MultiNet SSH session and there is no SSH:: in the translation
of SYS$REM_NODE. It contains the remotehostname and SYS$REM_NODE_FULLNAME
maintains the fully-qualified remotehostname. THere's no SSH:: found in
either translation.
MultiNet can optionally augment the FTA UCB to maintain TT_ACCPORNAM using
code I devised. You can check that field with F$getdvi("TT","TT_ACCPORNAM")
and look for "ssh".
I checked a SSH session on a OpenVMS V7.3 system with Multinet 5.0.
$ sh log sys$rem_node
"SYS$REM_NODE" = "SSH::" (LNM$JOB_85564680)
Maybe it changed in later versions.
>
> SSH under TCPIP Services I presume?
>
> Look in the JOB logical table. If the terminal is a pseudo-terminal
> and the JOB table logicals look like:
>
> "SYS$REM_ID" = "SSH_13579BDF"
> "SYS$REM_NODE" = "remotehostname.remotedomainname.tld::"
> "SYS$REM_NODE_FULLNAME" = "remotehostname.remotedomainname.tld::"
>
> I would say you might just have an SSH login.
Apparently it depends on the source of the SSH connections:
if the source of the ssh login is VMS with TCPIP services, then the real
VMS user name appears in SYS$REM_ID, no sign of SSH.
if login from other systems (in my case RH Linux), then yes, SSH_hexid is
there.
Probably TCPIP services SSH is doing some (private ?) protocol to get the
remote user name.
--
--
Joseph Huber, http://www.huber-joseph.de
I checked on Eisner (DECUServe.org) which is running:
$ MULTINET SHOW/VERSION
Process Software MultiNet V5.2 Rev A-X, AlphaServer DS20 500 MHz, OpenVMS AXP V8.3
Well, if it's TCPIP Services SSH, the FTA devices LOCKID will contain the
internal PID of the TCPIP$SSH_BGxxx process. I'll leave, as an exercise
for the reader, the details of converting from the IPID to the EPID as a
means of determining whether or not this is an SSH process FTA. ;)
HP TCP/IP Services for OpenVMS Alpha Version V5.6
on an AlphaServer XYZZY running OpenVMS V8.3
%%%%%%%%%%% OPCOM 28-OCT-2009 12:35:06.77 %%%%%%%%%%%
Message from user AUDIT$SERVER on XYZZY
Security alarm (SECURITY) on XYZZY, system id: 1369
Auditable event: Network login
Event time: 28-OCT-2009 12:35:06.76
PID: 000201B2
Process name: TCPIP$S_BG23326
Username: TCPIP$SSH
Process owner: [TCPIP$AUX,TCPIP$SSH]
Image name: XYZZYL$DKA0:[SYS0.SYSCOMMON.][SYSEXE]LOGINOUT.EXE
Remote node id: 1234567890 (12.345)
Remote node fullname: shuttlecock.badminton.net
Remote username: TCPIP$SSH
Posix UID: -2
Posix GID: -2 (%XFFFFFFFE)
%%%%%%%%%%% OPCOM 28-OCT-2009 12:35:07.71 %%%%%%%%%%%
Message from user AUDIT$SERVER on XYZZY
Security alarm (SECURITY) on XYZZY, system id: 1369
Auditable event: Detached process login
Event time: 28-OCT-2009 12:35:07.71
PID: 000201B3
Process name: _FTA120:
Username: SYSTEM
Process owner: [HEGEMONY,SYSTEM]
Terminal name: FTA120:
Image name: XYZZY$DKA0:[SYS0.SYSCOMMON.][SYSEXE]LOGINOUT.EXE
Posix UID: -2
Posix GID: -2 (%XFFFFFFFE)