FTP Login Failures

[VMS Unix Admin]

I am getting FTP login problems and at first they appeared to be intermittent. After doing a bit of testing, it looks like there may be some security stuff going on behind the scenes that I was not aware of. We are running OVMS 8.3 with vms83_sys v9 and vms83_update v6 installed and TCPIP v5.6 ECO2 on a GS1280.

Once there is a single login password failure, future attempts to login will fail until after some time period, then it starts working again or until you attempt to login from a different host. The strange thing (to me) is that subsequent failed login attempts are not captured in the system accounting file and not recorded in the login failure count as displayed in the sysuaf record for the FTP user. In addition, a successful login attempt does not reset the failed attempt counter to zero.

Is my understanding of how this should work wrong or is there a problem here?

Based on this FTP log file info, it looks like a problem to me, at least the failed login problem. I think the issue is the "duplicate name" error.

The events that triggered the log file entries provided were:
1. FTP login successful, then I logged out.
2. FTP login failed due to a bad password.
3. FTP login failed using a valid password(same account, a couple of attempts).
4. Switched to a different host to FTP from and the login worked.

%TCPIP-I-FTP_SESCON, FTP SERVER: session connection from azm7.mayo.edu at 6-AUG-2010 07:20:12.69
%TCPIP-I-FTP_USER, user name: ftptest
%TCPIP-I-FTP_SESDCN, FTP SERVER: session disconnection from azm7.mayo.edu at 6-AUG-2010 07:20:44.10
%TCPIP-I-FTP_SESCON, FTP SERVER: session connection from azm7.mayo.edu at 6-AUG-2010 07:20:47.04
%TCPIP-E-FTP_LOGFAL, remote interactive login failure ftptest
-TCPIP-I-FTP_NODE, client host name: azm7.mayo.edu
-LOGIN-F-INVPWD, invalid password
%TCPIP-I-FTP_SESCON, FTP SERVER: session connection from azm7.mayo.edu at 6-AUG-2010 07:21:22.66
%SYSTEM-F-DUPLNAM, duplicate name
%TCPIP-E-FTP_CREPRC, failed to create a child process
%TCPIP-I-FTP_NODE, client host name: azm7.mayo.edu
%TCPIP-I-FTP_USER, user name: ftptest
%TCPIP-I-FTP_OBJ, object: TCPIP$FTPC00003
%TCPIP-I-FTP_SESCON, FTP SERVER: session connection from azm7.mayo.edu at 6-AUG-2010 07:23:13.69
%SYSTEM-F-DUPLNAM, duplicate name
%TCPIP-E-FTP_CREPRC, failed to create a child process
%TCPIP-I-FTP_NODE, client host name: azm7.mayo.edu
%TCPIP-I-FTP_USER, user name: ftptest
%TCPIP-I-FTP_OBJ, object: TCPIP$FTPC00004
%TCPIP-I-FTP_SESCON, FTP SERVER: session connection from azm7.mayo.edu at 6-AUG-2010 07:25:32.74
%SYSTEM-F-DUPLNAM, duplicate name
%TCPIP-E-FTP_CREPRC, failed to create a child process
%TCPIP-I-FTP_NODE, client host name: azm7.mayo.edu
%TCPIP-I-FTP_USER, user name: FTPTEST
%TCPIP-I-FTP_OBJ, object: TCPIP$FTPC00005
%TCPIP-I-FTP_SESCON, FTP SERVER: session connection from azm8.mayo.edu at 6-AUG-2010 07:26:29.21
%TCPIP-I-FTP_USER, user name: FTPTEST
%TCPIP-I-FTP_SESDCN, FTP SERVER: session disconnection from azm8.mayo.edu at 6-AUG-2010 07:27:33.80

[RBrown_1]

It sounds like LGI_RETRY_LIM and LGI_BRK_LIM are set to 1. The default is 3 and 5 respectively.

Show us the results of $ MCR SYSGEN SHOW /LGI

[VMS Unix Admin]

LGI does not appear to be the issue. My gut feel is that it's an ECO issue...

Parameter Name Current Default Min. Max. Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
LGI_CALLOUTS 0 0 0 255 Count D
LGI_BRK_TERM 1 1 0 1 Boolean D
LGI_BRK_DISUSER 0 0 0 1 Boolean D
LGI_PWD_TMO 30 30 0 255 Seconds D
LGI_RETRY_LIM 3 3 0 255 Tries D
LGI_RETRY_TMO 20 20 2 255 Seconds D
LGI_BRK_LIM 5 5 1 255 Failures D
LGI_BRK_TMO 300 300 0 5184000 Seconds D
LGI_HID_TIM 300 300 0 1261440000 Seconds D

[RBrown_1]

Well that is all of my guesses. What does $ SHOW INTRUSION (need SECURITY privilege) tell you when you are unable to log in?

[The Brit]

I would check the

%SYSTEM-F-DUPLNAM, duplicate name
%TCPIP-E-FTP_CREPRC, failed to create a child process

Cannot create the child process because the process name is already in use.

Check that the process dies when you log out.

HTH

Dave.

[Hoff]

As other replies have mentioned, the direct error looks to be the expected behavior with certain intrusion settings.

Now whether those thresholds are being triggered prematurely here, that's another and open question. I've seen a few applications trigger those thresholds in that way - PATHWORKS Server had that behavior - though I've not seen that with FTP.

This:

%SYSTEM-F-DUPLNAM, duplicate name

looks like an (old!) FTP daemon bug might have returned?

That was seen around circa 5.0, IIRC.

If it's not intrusion, ring up HP support and have them take a look at this.

If that process creation stuff is really doing an n^2 process name search, um, well, that's certainly ugly.

Have a look at the (free) HGFTP package, if you need a fast replacement for this stuff; if this isn't intrusion settings and if HP doesn't have a rapid answer and an ECO available for the behavior on your schedule. That might move you forward.

[VMS Unix Admin]

You are on the right track! I was testing earlier today and I noticed a lot of dead FTP processes out there. After I deleted the orphaned processes and re-tested. The problem appears to be resolved and now works as expected...except for the failed login attempt counter in the sysuaf record. That still does not reset after a successful login attempt. However, that's a minor issue compared to the login issue.

Thanks.

[Hoff · Accepted solution]

The UAF failed-login counter is only reset upon an interactive login into the username. It is possible to clear the counter via a periodic (home-grown) $setuai tool (using documented interfaces), if there is never an interactive login with this username.

[VMS Unix Admin]

Thanks for the responses and thanks Hoff for clearing up my confusion on the failed login counter. I couldn't remember how it was supposed to work. I looked through the Authorize documentation but did not find an explanation. Unfortunately I'm doing more AIX work these days rather than VMS, so a lot of the technical details are fading...

I don't know why the FTP processes are being orphaned, yet. I'm still looking into that.

[Hoff]

Or see UAF> MOD user /FLAGS=DISREPORT