Telnet on another port + detect it

[Jan van den Ende]

Hi IP-guru's

Situation:

A (complex, 3rd party) peecee app (we can NOT change anything) that as one (important) part of its activities queries a VMS app.
VERY poor communication protocol:
- telnet connect
- expect at line 23 "Username:"
- expect at line 24 "Password:"
- expect at line 1

ANY exception => "Script error"

where exception can be things like "new mail" or "password has expired" or """Username:"" at wrong line" ... etc.

One 'good' part is that the Peecees where this runs need dedicated periferals, so they are known. We keep a list of them, and first thing in SYLOGIN check for that, and if found then short-circuit into the app (of course after checking applic authorisation, but "silent").

But now, several regions need to be able to get input from one-another.
And then we get into fire-wall/gateway issues.
What that means is: ALL external Telnet sessions are coming from a fire-wall address, an now NO more determinimg if this is a session for our famous app.

One potential escape: ALL external connections for this app are coming from a limited number of servers, which have no need for "normal" connections.

We so far have come up with the following scheme:
- the gateway detects the incoming telnet to be from one of the special servers.
- the session is re-routed to a port, other than the standard 23 (TBD, but for now, let's say 25)
- on VMS, we enable telnet to handle port 25
- sessions to port 25 are treated just like our current sessions from the dedicated peecees.

And now for the questions:

- what do I have to do to have telnet listening to port 25, as well as 23

- how do I determine that this session was using the special port?


TIA.

[Willem Grooters]

First, I would use a HIGHER port (> 1023, even > 10000). Be sure you do NOT interfere with other protocols (25 = SMTP. Mind GMS!!!!(Just to warn Jan....)).
Ok then.
your OWN PC's can use port 23 as they always did.
Other connections come in over firewall(s). You can direct each of them to virtually EVERY other port on the VMS box. If the sender is known, you could send every sender to his OWN port on VMS. Give EACH side it's own login and environment. Create a LOGIN.COM that fixes the user to THAT account. Do all login stuff in there, redefine eventually redefine SYS$INPUT and SYS$OUTPUT, and start the application.
Define this commandprocedure the handler for all traffic on that port:

TCPIP> SET SERVICE -
/PORT= -
/USER= -
/FILE=
TCPIP> SET CONFIG ENABLE SERVICE

I guess that would work.

Willem

[Jan van den Ende]

Willem,


Give EACH side it's own login and environment. Create a LOGIN.COM that fixes the user to THAT account. Do all login stuff in there,


and THAT is where the problem lies, and stays:
IF it was A fixed user, plain sailing.
But how about accountability?
(jeweetwel: Hoerenaccounts, iedereen zit erop maar niemand heeft het gedaan).

BUT: two-way NOT:
a. it will be dozens of users, subject to change with function changes
b. (some/most of) those users also need access to other applics.
(Willem, you may recognise FCM).

Port number: well, like I indicated, TBD, but I'm told it better not be in the non-prived range. Really up to network management. I just request "a" port for dedicated use, and will use what they give me.


Cheers

Have one on me.

jpe

[Willem Grooters]

Jan,

In case the firewall(s) do address and port translation / redirection, logging of what machine gains access to your machine will have to be done on the firewall(s). You are right that the VMS box will have NO WAY to determine the source.
That means you will have to get this data from the firewall(s), and will need to be able to process it in order to incorporate this into your accounting.
Still, it is worthwhile to have each server have it's own fixed IP-port. That would not be a problem - even if that will be a privileged port, thought I don't see the need.
Once a server has a connection, you know - by port number - which one it is. Next is to authenticate the user. Again this can be done by the firewall, in which case this will be logged on the firewall - and you'll need the logs even more.
On the VMS side I could think of running a kind of "authetication" program during LOGIN.COM, that signals the connection attempt and, eventually after having checked the user's credentials, sets the accounting data on VMS. AFAIK this resides in P1 space and is normally not accessable - it will required to have some privileged image to achieve this. In that case you do not have to change a lot in accounting (I've done this before a long time ago but it did work perfectly)

Willem

[Jan van den Ende]

Willem,


Still, it is worthwhile to have each server have it's own fixed IP-port. That would not be a problem - even if that will be a privileged port, thought I don't see the need.
Once a server has a connection,

>>>
you know - by port number - which one it is.
>>>



Willem, that _IS_ what this whole stream _IS_ about!!

___HOW___ do I know the port number?
If a do a GETJPI ACCPORNAM, then I get the port at the _REMOTE_ system from where the session is coming. But HOW do I get the _LOCAL_ port to which that session is connecting, or, alternatively, _HOW_ can I have two different instances of TELNET doing two different things?

Cheers.

Have one on me.

jpe

[Martin P.J. Zinser]

Hi Jan,

if you do have the port on the remote system you can parse the output of netstat -a and get the corresponding port on your end.

Greetings, Martin

[John Gillings]

Jan,

Find your physical terminal name with

$ phys=F$GETJPI("","TT_PHYDEVNAM")

then find the mapping with telnet :

$ telnet
TELNET> SHOW DEVICE TNA409:
TNA409: BG3077: Temporary Local: xara:23
Remote: TUNNEL:1220

[Antoniov. · Accepted solution]

Jan,
I guess you cannot set telnet service to listen port 23 (for internal sessions) and another port (for firewall sessions) concurrently.
I guess your firewall may assume a specific unique internal IP by using NAT; in this way you can recognize theese sessions by IP.

Antonio Vigliotti

[Willem Grooters]

Jan,

Let me give an example.

Your system is 10.1.1.10
The remote systems are 1.2.3.4 and 5.6.7.8

The firewall will divert traffic to 10.1.1.10 port 23 to any other, predestinated port on 10.1.1.10, based on the SOURCE address.

If 1.2.3.4 connects to 10.1.1.10:23 it will connect to port 23123
If 5.6.7.8 connects to 10.1.1.10:23, it will connect to port 23567

on VMS you have services:
/PORT=23123/FILE=LOGIN1234.COM/USER=EXTRNL
/PORT=23123/FILE=LOGIN5678.COM/USER=EXTRNL

or:

/PORT=23123/FILE=ELOGIN.COM/USER=EXTRNL1234
/PORT=23123/FILE=ELOGIN.COM/USER=EXTRNL5678

So either the commandprocedure that is started is different, or the user.

Willem

[Jan van den Ende]

Preliminary results:

Martin:
I do not see how I can (in SYLOGIN, remember?) recognise ___the__current__process__ in the mcr tcpip$netstat -a output.
Even IF I would know the remote port (which I do not), I do not see how that would gice me the required info

John:
THAT contains the info I would need, BUT: it works in keyboard input mode, but NOT from a command input file.
$ telnet
show device TNx
gives
TNAx: BGy: Temporary Local: node-interface:WANTED_PORT_NR

but
ty tmp.com
$ telnet
show device TNx

@ tmp
gives:
%SYSTEM-W-NODEVAVL
%SMG-F-INVPAS-ID
%DCL-W-SKPDAT

-- that IS consistent with the impossibility to do TELNET sessions from command procedures.
Would have been SO nice :-(

Antonio:
I am told that telnet listening to two ports can be done, so I hope you are wrong on that!

About the NAT solution: maybe, at the moment no Firewall specialist available.

Willem:


If 1.2.3.4 connects to 10.1.1.10:23 it will connect to port 23123
If 5.6.7.8 connects to 10.1.1.10:23, it will connect to port 23567

on VMS you have services:
/PORT=23123/FILE=LOGIN1234.COM/USER=EXTRNL
/PORT=23123/FILE=LOGIN5678.COM/USER=EXTRNL


I assume that on the last line you mean: /port=23567? :-)

Yes, THAT looks like the original idea of having an extra port to listen to, and have some different handling in that case.

Now we are back to the original question (in a more precise wording):

- what do I have to do to "on VMS you have services:"
(I think this exposes me as a real IP dummy, which essentially is true).

Please state the exact, complete syntax to get to "have these services", both Volatile and Permanent (if these concepts apply here?)

Are there any special things to be done the /FILE file?
What does /USER=EXTRNL mean? I intend the user to be validated against SYSUAF (and tested for the right to use the app against RIGHTSLIST, but that is trivial).

Cheers

Have one on me

Jan

[Jan van den Ende]

Antonio,

looks like jackpot for you!!

Firewall administrator reacted like: "Oh yeah, that's easy. Just one line in DNS and one line in plug-table."

-- And for me, I now only have to add this firewall-alias to my table of (up till now) PeeCees that get the special processing.

Sounds terrific!!!

I will wait to close this thread till it is demonstrated working, though.


Cheers

Have one on me.

Jan

[Jan van den Ende]

PS

Martin,

answer this link please,
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=708566
so I can close it.

Cheers.

Have one on me.

jpe

[Bojan Nemec]

Jan,

Probably Antonios sugestion will be the best solution. About creating a telnet service on another port the "magic" flag is Rtty (not well documented). So you can do it in TCPIP>

TCPIP> set service mytelnet -
/port=20023/inact=1/limit=10000 -
/proc="not_defined"/user=system -
/flag=rtty /file=TCPIP$TELNET_RUN.COM -
/socket=(keep,receiv:3000,send:3000) -
/log=(activ,noaddr,deact,conn,error,login,logout,modify,reject)
TCPIP> enable service mytelnet
TCPIP> set communication enable service mytelnet

The /proc /user and /file will be ignored and normal login (with username:,password...) will be active.

To get the local port of the telnet session, that is another thing. The only way (I know) is thru telnet prompt, but as you have seen this is only interactive. With the pipe command it will be oportune to review some (or all) VMS commands, so that they will work in a pipe (RSH also does not work in a pipe).

Bojan

[Willem Grooters]

Jan,

Like I said: let firewalls do the job in redirecting. That's what their good at. I just doubt your firewall 'specialist'. This has to do with filtering and redirecting traffic from a given source to a specific destination address, wnot with name translation....

This being said:

- what do I have to do to "on VMS you have services:"
(I think this exposes me as a real IP dummy, which essentially is true).


You have to start somehwere...IWT


Please state the exact, complete syntax to get to "have these services", both Volatile and Permanent (if these concepts apply here?)


Bojan's last entry (though I think there is some error):
$ TCPIP
TCPIP> SET SERVICE...
defines the service on port /PORT, stating what commandprocedure will be started when accessed (/FILE=) and under which user that will happen (/USER=)
FILE can be any commandprocedure - see my previous posts. It can exist on any place you specify but be sure when using logicals, EACH should be defined /SYSTEM. Default the file is sought on SYS$LOGIN of /USER.
By default, a service is disabled
TCPIP> ENABLE SERVICE ...
Does exactly what is does - and will check the validity of /USER (must exists, with some extra requirements (NODISUSER, NOCAPTIVE (I think)).
After reboot, the service will be disabled!
TCPIP> SET CONFIGURATION ENABLE SERVICE...
Creates an entry in the permanent database that the given service will be enabled after reboot.

The way TCPIP$INET works - in general:
* Checks user that will run the service
* Logs this user in (the whole lot)
* Locates and executes /FILE
* logs out

When not suppressed (and I would suggest you do NOT) a logfile .LOG will be created in SYS$LOGIN of /USER.
When /FILE is not found, you'll find "Cannot find SYS$LOGIN" or so in there.
You can of course put more output...


Are there any special things to be done the /FILE file?


Not really. As stated, you may need to do some extra login.


What does /USER=EXTRNL mean? I intend the user to be validated against SYSUAF (and tested for the right to use the app against RIGHTSLIST, but that is trivial).


Some stupidly chosen username...
As said, this user must exist in SYSUAF before you can enable (or even define) the service. When the service starts, TCPIP$INET will execute LOGINOUT.EXE on behalf of this user - he will actually log in.

Willem

[Jan van den Ende]

Willem,


just doubt your firewall 'specialist'.



No need to!

Actually he is one of the few of that ilk that is convinced that names (including aliasses) are much more transparent & maintainable than tables with numbers.

I know __I__ agree with that!! I hate learning tons of alike-looking numbers by head, and even more so if they have the nasty habit of changing every once in a while
(in any failover situation, flipping ONE dns name beats the hell out of changing the target address on 3500+ clients!!

And maintaining (and troubleshooting!) all those Permit and Plug tables is worry enough on reasonable names, but if you just have adresses and port numbers... including again the issue of failovers.

No, this setup is really in a VMS-like kind of logical name style, rather than the more direct-hard coded style so common in *IX environments (and he really IS a NIXian)


On the SERVICE issue (if NAT works, we will not need it now, but it is always good to learn)
If I read Bojan correct, the /FILE is ignored?


Cheers.

Have one on me.

jpe

[Bojan Nemec]

Jan,

You read correct /proc /user and /file are ignored but must be present to create and start the service. The user and file must exist, but they are not used. The command in my previous works fine (tested another time with copy/paste from the post).

Writing this, I get some new idea abbout the local port number. It was not a good idea, but after some searching about BG devices and so on I found that there are some special qio functions for the telnet driver. So there is a program. It is ougly writen and returns the port in $STATUS !!! But I have no languages on hands and the program is in MACRO32. See atachement. Sorry for this but I want to test it.

Bojan

PS
Is Friday evening - Have one on me.

[Bojan Nemec]

My previous example was to ougly. Could not resist and improved it a bit. If you run it on a telnet terminal it will set a symbol with name PORT and (probably) value "____23" (read _ as blank). On a mytelnet session created with the command I posted, the symbol gets a value of "_20023". Did not test it on another type of terminal but it will probably return an error.

Bojan

[Jan van den Ende]

So Bojan & Willem,

can I conclude that it is both possible to HAVE the /FILE=file executed, or not executed?
I _think_ I found the difference in specifying /RTTY ?

And, if /FILE _is_ executed, at what time is that? Ahead of SYS$SYLOGIN, after it but before LOGIN.COM, after that, or instead of some or all?



Anyway, for the real issue at hand, we are first trying Antonio's NAT route. It is already set up, now I am trying to get synchronised the various people who should execute/monitor/massage the test. Not before next week.


Cheers.

Have one on me.

jpe

[Bojan Nemec]

Jan,

If you specify /FLAGS=RTTY the /FILE=file is NOT executed. If you ommit /FLAGS=RTTY the file is executed but you have lost the login procedure (probably LOGINOUT.EXE) the user becomes the one defined by the /USER and the process name is managled from the /PROC value and a sequential number.

I agree with you, that Antonios NAT route is the simpliest way (and simple things just work), but the problem was so interesant to me that I could not resist to try to resolve it.

(By the way, when I transfer the program to my linux I made a typo. The blbc r0,end must realy be blbc r0,err.)

Bojan

[Willem Grooters]

From what I observed using services, the procedure specified as /FILE needs to be found regardless /USER specified. It will be executed after this user has been logged in - that is: SYLOGIN and user-LOGIN.COM have been executed. As a result:
1. Access on port triggers TCPIP$INET to work - it will set up the BG device and define SYS$NET.
2. Locate /USER
3. Locate /FILE
4. execute SYLOGIN.COM
5. Execute /USER LOGIN.COM
6. Execute /FILE This will havce to do all processing!
7. Logout when /FILE finishes.
8. Free devices (at least, it should)

The reason why the location of /FILE is done before login is likely a security measure.

Willem

[Bojan Nemec]

Willem,

Great description. Services on VMS works yust like you describe and are great to write task to task communication. They are very similar to DECnet objects.

I will try to describe a service with a RTTY flag, which works slightly different:
1. Access on port triggers TCPIP$INET to work - it will set up the BG device.
2. Creates a TN device connected to the BG device

From there just like normal terminal login

3. Execute LOGINOUT.EXE on the TN device - (which sets the user, process name, etc depending on the entered username)
4. Execute SYLOGIN.COM
5. Execute LOGIN.COM
6. Start the DCL prompt

As you can see the /FILE is not executed, but must be a valid and existing file because is checked when you do the ENABLE SERVICE (or startup). In my previous example I put the TCPIP$TELNET_RUN.COM for the /FILE, this is a rest of my testing, the /FILE name can be any existing file on the system.

You can try how it works yust copy/pasting the SET SERVICE command from my previous post in the TCPIP prompt. Then do the ENABLE SERVICE command. Omitt the SET CONFIGURATION which will write the anble service in the permanent database. Try a telnet yourhost 20023. Now you have a normal telnet session. If you do TELNET> SHOW DEVICE you will see that the local port is 20023 and not 23. You can also try my litle program from the previous post. When finished with testing you can remove the service with the TCPIP command SET NOSERVICE mytelnet.

Bojan

[John Gillings]

Jan,

Since the TELNET client can do it, obviously a program can find the information you need. I've attached a rather ugly (but completely self contained) MACRO32 program that will find the port numbers for a given TNA device. It's a foreign command, so use:

$ TNBG 'F$GETJPI("","TT_PHYDEVNAM")

the program will define 4 local symbols

TNBG_ACCPORNAM - sanity check, and contains the remote host name
TNBG_BGDEVICE - the associated BG device name
TNBG_LOCAL_PORT - the port number on the local host
TNBG_REMOTE_PORT - the port number on the remote host

How to use, theory of operation, translation to favourite language, cleaning up, and ongoing support left as an exercise.

[Willem Grooters]

Jan,

One day I've had to deal with a firewall 'specialist', who set this up by defining one DNS for reseolving names outside the firewall and one doing this for the inside. The outside-DNS kept the real IP address of a node, and the inside-DNS the gateway's address for the same one. Though this is feasable (if properly defined) I wouldn't recommend it for its clearness...
Of course, it went wrong someone else had to deal with it....

Willem

[Jan van den Ende]

So,

it took some time to get all required people activated at the same time (at several sites other priorities were raised).

Then there were some minor applic & authorisation details, but...

Hallelujah!!

Antonio, I noted you had only one entry in this stream, but you indeed HAD the jackpot!

Now our firewall on the inside has an alias IP address, and the plug-tables recognise when a user wants this applic. The session gets plugged to the alias, which in VMS is recognised as a "separate" source.
SYS$SYLOGIN recognises that, and the rest is old stuff.

Many thanks to all who put in effort to solve this for us!


Cheers.

Have one on me. (well, weekend coming, make that SOME)

Jan

[Antoniov.]

Wow Jan,
I'm sorry but I'm very busy.
I disabled response e-mail but I've forgotten for this thread. If I called by e-mail I don't resist and I go into this forum.

Antonio Vigliotti
P.S.
Congratulation to Uwe.