Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

SSH footprint

109 views
Skip to first unread message

Marc Van Dyck

unread,
Oct 26, 2009, 3:17:00 PM10/26/09
to
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), the corresponding audit entry says that
the user SSH did a remote login, instead of displaying the real user.

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


Dale Dellutri

unread,
Oct 26, 2009, 4:00:50 PM10/26/09
to

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)

Wilm Boerhout

unread,
Oct 26, 2009, 3:59:41 PM10/26/09
to
Marc Van Dyck mentioned on 26-10-2009 20:17:

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

VAXman-

unread,
Oct 26, 2009, 5:04:44 PM10/26/09
to

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?"

Wilm Boerhout

unread,
Oct 26, 2009, 4:05:01 PM10/26/09
to
Dale Dellutri mentioned on 26-10-2009 21:00:

DECnet terminals (SET HOST) use RTAn:

/Wilm

Marc Van Dyck

unread,
Oct 26, 2009, 4:29:43 PM10/26/09
to
VAXman- @SendSpamHere.ORG was thinking very hard :

OK, will try that at work tomorrow morning. Many thanks to all who
responded !

--
Marc Van Dyck


Marc Van Dyck

unread,
Oct 26, 2009, 4:32:58 PM10/26/09
to
Marc Van Dyck submitted this idea :

> 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), the corresponding audit entry says that
> the user SSH did a remote login, instead of displaying the real user.
>
Do you believe it is worth asking HP to solve that problem ?

--
Marc Van Dyck


VAXman-

unread,
Oct 26, 2009, 5:49:59 PM10/26/09
to

FTAs do not, by default, employ TT_ACCPORNAM.

Bob Gezelter

unread,
Oct 26, 2009, 5:01:48 PM10/26/09
to
> Marc Van Dyck

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

Marc Van Dyck

unread,
Oct 26, 2009, 5:10:39 PM10/26/09
to
on 26/10/2009, Bob Gezelter supposed :

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


JBloggs

unread,
Oct 26, 2009, 5:20:26 PM10/26/09
to
On Mon, 26 Oct 2009 20:17:00 +0100, Marc Van Dyck
<marc.v...@brutele.be> wrote:

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
$! ...


Richard Maher

unread,
Oct 26, 2009, 6:18:51 PM10/26/09
to
Hi Marc,

"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
>


Richard B. Gilbert

unread,
Oct 26, 2009, 8:18:47 PM10/26/09
to

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!

Barratt, Chris (Health)

unread,
Oct 26, 2009, 9:12:00 PM10/26/09
to comp.os.vms to email gateway

>
> 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.

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

Fred Zwarts

unread,
Oct 27, 2009, 4:41:06 AM10/27/09
to
Marc Van Dyck <marc.v...@brutele.be> typed
(in mn.d4c17d9a41...@brutele.be)

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::"

VAXman-

unread,
Oct 27, 2009, 8:46:29 AM10/27/09
to
In article <mailman.61.1256605938.1...@rbnsn.com>, "Barratt, Chris (Health)" <Chris....@health.sa.gov.au> writes:
>
>>=20

>> 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:."
>>=20

>> 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.
>>=20

>> I'm not sure how to rule out DECnet.
>
>I have done it by checking doing a f$getdvi(term,"TT_SECURE"), which was no=
>t set for Decnet FTA processes but was for SSH FTA processes.=20

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.

VAXman-

unread,
Oct 27, 2009, 8:54:07 AM10/27/09
to
In article <hc6bn3$6sg$1...@news.albasani.net>, "Fred Zwarts" <F.Zw...@KVI.nl> writes:
>Marc Van Dyck <marc.v...@brutele.be> typed
>(in 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), the corresponding audit entry says
>> that the user SSH did a remote login, instead of displaying the real
>> user.=20
>>=20

>> 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.
>>=20

>> 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 ?
>>=20

>> Thanks in advance,
>
>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 =3D f$trnlnm("SYS$REM_NODE") .eqs. "SSH::"

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".

Fred Zwarts

unread,
Oct 27, 2009, 8:48:45 AM10/27/09
to
VAXman- @SendSpamHere.ORG <VAXman- @SendSpamHere.ORG> typed
(in 00A93A63...@SendSpamHere.ORG)

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.

Joseph Huber

unread,
Oct 27, 2009, 9:15:22 AM10/27/09
to
VAXman- @SendSpamHere.ORG wrote:

>
> 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

VAXman-

unread,
Oct 27, 2009, 1:20:49 PM10/27/09
to
In article <hc6q7e$s06$1...@news.albasani.net>, "Fred Zwarts" <F.Zw...@KVI.nl> writes:
>VAXman- @SendSpamHere.ORG <VAXman- @SendSpamHere.ORG> typed
>(in 00A93A63...@SendSpamHere.ORG)
>> In article <hc6bn3$6sg$1...@news.albasani.net>, "Fred Zwarts"
>> <F.Zw...@KVI.nl> writes:=20

>>> Marc Van Dyck <marc.v...@brutele.be> typed
>>> (in 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), the corresponding audit entry
>>>> says that the user SSH did a remote login, instead of displaying
>>>> the real user.=3D20
>>>> =3D20

>>>> 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.
>>>> =3D20

>>>> 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 ?
>>>> =3D20
>>>> Thanks in advance,
>>>=20

>>> You don't say which TCP/IP implementation you use.
>>> We use Multinet 5.0 and in our SYLOGIN.COM the check looks like:
>>>=20
>>> $ SSH_LOGIN =3D3D f$trnlnm("SYS$REM_NODE") .eqs. "SSH::"
>>=20

>> I checked a MultiNet SSH session and there is no SSH:: in the
>> translation=20

>> of SYS$REM_NODE. It contains the remotehostname and
>> SYS$REM_NODE_FULLNAME maintains the fully-qualified remotehostname.=20
>> THere's no SSH:: found in=20
>> either translation.
>>=20

>> MultiNet can optionally augment the FTA UCB to maintain TT_ACCPORNAM
>> using=20

>> code I devised. You can check that field with
>> F$getdvi("TT","TT_ACCPORNAM")=20

>> 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" =3D "SSH::" (LNM$JOB_85564680)

>
>Maybe it changed in later versions.
>

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

VAXman-

unread,
Oct 27, 2009, 1:25:46 PM10/27/09
to

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. ;)

Jose Baars

unread,
Oct 28, 2009, 12:01:34 PM10/28/09
to
I seem to remember having installed a point fix for SSH
from HP for this exact problem.
If you have a support contract it's always a good idea to report
it, it's what you pay for, and very often you get a fix.

VAXman-

unread,
Oct 28, 2009, 1:44:45 PM10/28/09
to


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)

0 new messages