Re: telnet exit points -- MIDRANGE-L

I was just looking through WRKREGINF at the available exit points. There
seem to be only two in my release related to telnet. It's not clear to me
whether it's possible to insert my logic before the telnet client ever
gets a signon screen or not.

First of all, not all telnet clients get a sign on screen. It's possibleto pass all of the signon screen fields as variables from the client(userid, password, program, menu and curlib) when the session isestablished. If you do that, there won't be a signon screen at all.

In fact, because it's possible to send an encrypted password this way,it's actually more secure than presenting a signon screen and allowing theuser to type. (Though, IMHO, if the signon screen is SSL encrypted,that's more secure yet.)

At any rate, the QIBM_QTG_DEVINIT exit point DOES fire off before thesign-on screen. The only way you can check userid/password fields in thatexit point is if they're passed as part of the session start up.

This exit point is frequently used to determine which device a telnetsession is associated with -- therefore, it MUST fire off before thesignon screen.

Another exciting thing about this exit program is that it can be used toverify the users password if it's passed as part of those session setupvalues. So, you can write logic to accept or not accept the password,even if the system wouldn't have allowed it. Indeed, it's really easy towrite code that says "always accept every password" (really, just a matterof setting a parameter to '1') and then all users passwords will always beaccepted whether they're correct or not.

That way, I can log on as QSECOFR, for example, and type a bogus password.It'll let me in anyway, because the exit program says it's okay. Cool,eh?

The point I'm trying to make is -- make sure this program is secured.Anyone who can install a program to it, or change an existing program, hasaccess to do anything they want to your system.

It looks to me as if QIBM_QTG_DEVINIT is post-signon.

It's not. Unless, of course, you use the "bypass sign-on" feature thatsends the sign-on info as part of the session setup. In which case, it'sin the middle of th signon process.

I want to be able to hang up on people before they ever see the signon
screen. Possible through exit points?

Yes, but foolish. You see, you're allowing the users to create aconnection to the iSeries, but then denying it. If they want to hurt youin some way, they can write a program that will create thousands ofconnection attempts very quickly, and it'll be a denial of service attack.

Or, they can look for flaws in your program logic and try to use them tobypass your security.

A smarter way to block people from getting a signon screen is to use afirewall. A firewall will prevent the connection from ever beingestablished in the first place.