Many open FTP connections

[Dario Karlen]

Hey guys

We have a OpenVMS cluster with V 8.3
There are six different alarmpanels, which get a generated file every 5 seconds via FTP. Sometimes during the day some people get shiftreports also via ftp. The files are very small, only a few KB. But when I check the processes, there are always a lot of different opne ftp connections, why? can I find out which ip address the source is?
here's a printout of the show proc and a detailed info for such a process. hope somebody have got an idea. thanks in advance.

211EB53B TCPIP$FTPC09EA5 LEF 9 299 0 00:00:00.36 477 427 N
211E853D TCPIP$FTPC09EA7 LEF 9 210 0 00:00:00.04 477 427 N
211DD93E TCPIP$FTPC09EA8 LEF 9 186 0 00:00:00.04 470 420 N
211EFD3F TCPIP$FTPC09EA9 LEF 9 186 0 00:00:00.03 470 420 N
211B8D40 TCPIP$FTPC09EAA LEF 9 153 0 00:00:00.05 470 420 N
211C0141 TCPIP$FTPC09EAB HIB 10 109 0 00:00:00.02 410 368 N
2115AD49 RO2 LEF 4 5219149 0 00:07:21.10 615 579
211ED561 _TNA4284: LEF 4 334633 0 00:00:19.99 565 506
211DBD86 _TNA4292: LEF 8 96255 0 00:00:04.96 555 483
2112DDC8 _TNA4257: LEF 4 1218058 0 00:00:58.94 614 592
211BFDEF _TNA4265: LEF 6 200214 0 00:00:14.74 557 498
2119EDFC _TNA4113: LEF 9 6633229 0 00:06:03.15 621 613
211BB635 TCPIP$FTPC9C850 HIB 10 189 0 00:00:00.04 477 427 N
211A2636 TCPIP$FTPC9C851 HIB 10 108 0 00:00:00.04 410 368 N
210E0637 TCPIP$FTPC9C852 HIB 10 107 0 00:00:00.04 410 368 N
211C2A38 TCPIP$FTPC9C853 HIB 10 108 0 00:00:00.04 410 368 N
211D8E39 TCPIP$FTP_3 LEF 8 5885802 0 00:02:29.33 1217 914 N
21107249 TCPIP$FTPC9EC1B HIB 10 138 0 00:00:00.28 473 419 N
2110724A TCPIP$FTPC9EC1C HIB 10 99 0 00:00:00.19 421 374 N
2110724B TCPIP$FTPC9EC1F HIB 10 155 0 00:00:00.27 469 419 N
2110724C TCPIP$FTPC9EC1D HIB 10 113 0 00:00:00.18 414 372 N
210ECE4D TCPIP$FTPC9EC20 HIB 10 155 0 00:00:00.41 469 419 N
21106E4E TCPIP$FTPC9EC21 HIB 10 110 0 00:00:00.21 410 368 N
2110724F TCPIP$FTPC9EC22 HIB 10 110 0 00:00:00.22 410 368 N
21101E50 TCPIP$FTPC9EC23 HIB 10 98 0 00:00:00.22 417 370 N
210DAE51 TCPIP$FTPC9EC24 HIB 10 93 0 00:00:00.17 410 368 N
21100E52 TCPIP$FTPC9EC25 HIB 10 98 0 00:00:00.19 417 370 N
210E9253 TCPIP$FTPC9EC26 HIB 10 97 0 00:00:00.26 410 368 N
210FBA54 TCPIP$FTPC9EC1E HIB 10 95 0 00:00:00.19 417 370 N
21106A55 TCPIP$FTPC9EC27 HIB 10 96 0 00:00:00.19 410 368 N
21107256 TCPIP$FTPC9EC28 HIB 10 93 0 00:00:00.23 410 368 N
21105E57 TCPIP$FTPC9EC2A HIB 10 93 0 00:00:00.26 410 368 N
21107258 TCPIP$FTPC9EC2C HIB 10 95 0 00:00:00.20 410 368 N
21107259 TCPIP$FTPC9EC2E HIB 10 94 0 00:00:00.24 410 368 N
210B5E5A TCPIP$FTPC9EC2F HIB 10 94 0 00:00:00.27 410 368 N
210FCA5B TCPIP$FTPC9EC32 HIB 10 94 0 00:00:00.26 410 368 N
2110725C TCPIP$FTPC9EC34 HIB 10 93 0 00:00:00.17 410 368 N
210D965D TCPIP$FTPC9EC29 HIB 10 94 0 00:00:00.16 410 368 N

detailed info:
ina > sh proc /id=2110724B

13-FEB-2008 13:39:59.61 User: ANONYMOUS Process ID: 2110724B
Node: ALESA1 Process name: "TCPIP$FTPC9EC1F"

Terminal:
User Identifier: [ANONY,ANONYMOUS]
Base priority: 8
Default file spec: Not available
Number of Kthreads: 1
ina > sh proc /id=2110724B /all

13-FEB-2008 13:40:04.47 User: ANONYMOUS Process ID: 2110724B
Node: ALESA1 Process name: "TCPIP$FTPC9EC1F"

Terminal:
User Identifier: [ANONY,ANONYMOUS]
Base priority: 8
Default file spec: Not available
Number of Kthreads: 1

Process Quotas:
Account name: ANONY
CPU limit: Infinite Direct I/O limit: 100
Buffered I/O byte count quota: 126976 Buffered I/O limit: 400
Timer queue entry quota: 49 Open file quota: 95
Paging file quota: 502560 Subprocess quota: 10
Default page fault cluster: 64 AST quota: 98
Enqueue quota: 293 Shared file limit: 0
Max detached processes: 0 Max active jobs: 0

Accounting information:
Buffered I/O count: 86 Peak working set size: 6704
Direct I/O count: 69 Peak virtual size: 178096
Page faults: 469 Mounted volumes: 0
Images activated: 1
Elapsed CPU time: 0 00:00:00.27
Connect time: 36 20:39:20.38

Authorized privileges:
NETMBX TMPMBX

Process privileges:
NETMBX may create network device
TMPMBX may create temporary mailbox

Process rights:
ANONYMOUS resource
NETWORK

System rights:
SYS$NODE_ALESA1

Auto-unshelve: on

Image Dump: off

Soft CPU Affinity: off

Parse Style: Traditional

Case Lookup: Blind

Units: Blocks

Token Size: Traditional

Home RAD: 0

Scheduling class name: none

There is 1 process in this job:

TCPIP$FTPC9EC1F (*)

[Wim Van den Wyngaert]

to get the IP (under label REMOTE):
$ tcpip show dev/port=21/full

1 of the devices is the listener.

Reason : ftp is kept open by the client (e.g. at prompt or a GUI is kept open) ?

Wim

[Willem Grooters]

A wild shot:
Count the number of FTP processes: quite likely you will find 100 at most ;)
LIMIT set to 1000 means a maximum of 100 concurrent sessions. Is it likely you have that much concurrent? Lowering LIMIT would at least lower the number of processes and occupied ports.

It could be that ports are kept by the server to speed up connectivity (FTP server internals, so I cannot tell). Lowering LIMIT would limit this number as well.

Another possibility is that the FTP client (sending the files) does not close the connection ("BYE") but simply aborts the client. In some OS's theis seems the proper way of doing things :(. The server has no clue and will still connect to the port.

[Wim Van den Wyngaert]

Keepalive isn't enabled by default on FTP.
May be clients did a power off of their PC. Thus the connection will stay until the PC reboots.

WIm

[Karl Rohwedder]

Have a look at some logical names to control the TCPIP behaviour, esp. TCPIP$FTPD_IDLETIMEOUT and TCPIP$FTPD_KEEPALIVE.

regards Kalle

[Volker Halle · Accepted solution]

Dario,

the FTP client process shown was apparently hanging around since 36 days...

You can check with SDA, if the FTP client process (TCPIP$FTPCx) has an IP device socket assigned (BG device). If it hasn't, there is no data transfer going on at the moment.

$ ANAL/SYS
SDA> SHOW PROC/CHAN/ID=

If you see a BG device, try

SDA> TCPIP SHOW DEV BGxxxx:

this will tell you the remote IP address and port.

If there is no BG device, there is no easy way to find out, which remote node has started this process.

If none of the FTP logicals or idle timeout helps, you could write some procedure to kill TCPIP$FTPCx process, if they are not consuming any CPU/IO and have an uptime of more than xx hours.

Volker.

[Wim Van den Wyngaert]

If you find unused connection you can terminate them with
$ tcpip disconn dev bgxxx

Wim

[Dario Karlen]

I tried something you suggested.
First: all the clients close the ftp connection properly with "BYE".

There are no such logicals TCPIP$FTPD_IDLETIMEOUT or TCPIP$FTPD_KEEPALIVE. I found only these logicals:
$ sh log tcpip$ftp*

(LNM$PROCESS_TABLE)

(LNM$JOB_88D52C40)

(LNM$GROUP_000001)

(LNM$SYSTEM_TABLE)

"TCPIP$FTP_EXTLOG" = "1"
"TCPIP$FTP_IMBX" = "MBA25077:"
"TCPIP$FTP_RMBX" = "MBA25076:"
"TCPIP$FTP_TMBX" = "MBA25078:"

(LNM$SYSCLUSTER_TABLE)

(DECW$LOGICAL_NAMES)
$

To solve my problem I stopped and restarted the FTP server, it seems to be better now.
But I found a huuuge anonymous ftp log. how can I disable the log for the anonymous login?

Now I can see only one activ FTP process, which uses a lot of CPU time and IO counts. but I have no clue where its coming from, here the analysis:
SDA> show proc/chan/id=2113FE8A














Process index: 028A Name: TCPIP$FTP_1 Extended PID: 2113FE8A
--------------------------------------------------------------------


Process active channels
-----------------------

Channel CCB Window Status Device/file accessed
------- --- ------ ------ --------------------
0010 7FF26000 00000000 DSA0:
0020 7FF26020 88DA3C80 DSA0:[VMS$COMMON.SYSEXE]TCPIP$FTP_SERVER
.EXE;1 (section file)
0030 7FF26040 88798440 DSA0:[VMS$COMMON.SYSLIB]SECURESHRP.EXE;1
(section file)
0040 7FF26060 8879B2C0 DSA0:[VMS$COMMON.SYSLIB]SECURESHR.EXE;1
(section file)
0050 7FF26080 887A7480 DSA0:[VMS$COMMON.SYSEXE]DCL.EXE;1 (secti
on file)
0060 7FF260A0 88799440 DSA0:[VMS$COMMON.SYSLIB]DCLTABLES.EXE;91
(section file)
0070 7FF260C0 892FD480 DSA0:[TCPIP$FTP]TCPIP$FTP_RUN.LOG;41
0080 7FF260E0 88C9D500 DSA0:[VMS$COMMON.SYSEXE]TCPIP$FTP_RUN.CO
M;1
0090 7FF26100 88799640 DSA0:[VMS$COMMON.SYSLIB]LIBOTS.EXE;1 (se
ction file)
00A0 7FF26120 887995C0 DSA0:[VMS$COMMON.SYSLIB]LIBRTL.EXE;1 (se
ction file)
00B0 7FF26140 8879B840 DSA0:[VMS$COMMON.SYSLIB]CMA$TIS_SHR.EXE;
1 (section file)
00C0 7FF26160 8879D740 DSA0:[VMS$COMMON.SYSLIB]DECC$SHR.EXE;1 (
section file)
00D0 7FF26180 8879CFC0 DSA0:[VMS$COMMON.SYSLIB]DPML$SHR.EXE;1 (
section file)
00E0 7FF261A0 8879AAC0 DSA0:[VMS$COMMON.SYSLIB]MAILSHR.EXE;1 (s
ection file)
00F0 7FF261C0 887979C0 DSA0:[VMS$COMMON.SYSLIB]MAILSHRP.EXE;1 (
section file)
0100 7FF261E0 8883A0C0 DSA0:[VMS$COMMON.SYSLIB]TCPIP$ACCESS_SHR
.EXE;1 (section file)
0110 7FF26200 890FE640 DSA0:[VMS$COMMON.SYSLIB]SYS$PUBLIC_VECTO
RS.EXE;1
0120 7FF26220 8883A7C0 DSA0:[VMS$COMMON.SYSLIB]TCPIP$IPC_SHR.EX
E;1 (section file)
0130 7FF26240 88839EC0 DSA0:[VMS$COMMON.SYSMSG]TCPIP$MSG.EXE;1
(section file)

Press RETURN for more.
SDA>

Process index: 028A Name: TCPIP$FTP_1 Extended PID: 2113FE8A
--------------------------------------------------------------------

Channel CCB Window Status Device/file accessed
------- --- ------ ------ --------------------
0140 7FF26260 887ABF80 DSA0:[VMS$COMMON.SYSMSG]SHRIMGMSG.EXE;1
(section file)
0150 7FF26280 887AAF00 DSA0:[VMS$COMMON.SYSMSG]DECC$MSG.EXE;1 (
section file)
0160 7FF262A0 887AB880 DSA0:[VMS$COMMON.SYSMSG]CLIUTLMSG.EXE;1
(section file)
0170 7FF262C0 00000000 Busy BG13053:
0180 7FF262E0 00000000 MBA25076:
0190 7FF26300 00000000 MBA25077:
01A0 7FF26320 00000000 MBA25078:
01B0 7FF26340 00000000 BG1061:
01D0 7FF26380 8883AB40 DSA0:[VMS$COMMON.SYSLIB]UCX$IPC_SHR.EXE;
1 (section file)
01E0 7FF263A0 8927C800 DSA0:[VMS$COMMON.SYSEXE]RIGHTSLIST.DAT;1
01F0 7FF263C0 88890000 DSA0:[TCPIP$FTP]TCPIP$FTP_ANONYMOUS.LOG;
1

Total number of open channels : 30.
SDA> tcpip show dev BG13053:
Port Remote
Device_socket Type Local Remote Service Host

BG13053 Stream 21 0 FTP LISTEN
SDA>
$ sh proc /all /id=2113FE8A

15-FEB-2008 11:15:39.18 User: TCPIP$FTP Process ID: 2113FE8A
Node: ALESA1 Process name: "TCPIP$FTP_1"

Terminal:
User Identifier: [TCPIP$AUX,TCPIP$FTP]
Base priority: 8
Default file spec: Not available
Number of Kthreads: 1

Devices allocated: BG13053:
BG31910:

Process Quotas:
Account name: TCPIP
CPU limit: Infinite Direct I/O limit: 100
Buffered I/O byte count quota: 118720 Buffered I/O limit: 100
Timer queue entry quota: 49 Open file quota: 95
Paging file quota: 494896 Subprocess quota: 10
Default page fault cluster: 64 AST quota: 246
Enqueue quota: 284 Shared file limit: 0
Max detached processes: 0 Max active jobs: 0

Accounting information:
Buffered I/O count: 9861283 Peak working set size: 16320
Direct I/O count: 3499736 Peak virtual size: 187376
Page faults: 1204 Mounted volumes: 0
Images activated: 3
Elapsed CPU time: 0 00:05:46.53
Connect time: 1 00:12:23.53

Authorized privileges:
NETMBX TMPMBX

Process privileges:
NETMBX may create network device
TMPMBX may create temporary mailbox

Process rights:
TCPIP$FTP resource
NETWORK

System rights:
SYS$NODE_ALESA1

Auto-unshelve: on

Image Dump: off

Soft CPU Affinity: off

Parse Style: Traditional

Case Lookup: Blind

Units: Blocks

Token Size: Traditional

Home RAD: 0

Scheduling class name: none

There is 1 process in this job:

TCPIP$FTP_1 (*)
$

Thanks
Dario

[Volker Halle]

Dario,

the TCPIP$FTP_1 process is the FTP server process, which handles the control connections. Data connections are typically handled via TCPIP$FTPCxxxxxx processes.

BG13053 is the listening socket in your case.
But what about BG1061: ?

You need to create some of the TCPIP$FTP logicals, if you want to activate idle timeout or keepalive. Please see the TCPIP documentation.

The entries in TCPIP$FTP_ANONYMOUS.LOG will allow you to see the anonymous FTP activity. Disabling this file may be possible by defining the TCPIP$FTP_ANONYMOUS logical to point to NLA0:

Volker.

[Willem Grooters]

Allthough the logfile is huge, it's worh to take a look at it. Search for lines containing SESCON en SESDCN (Session connect / disconnect). It will tell you the system and moment of connection/disconnection (and by that, the duration of the session) including errors during the session.
Security requirements may prohibit suppression of this logfile.
If your FTP server is accessable from the Internet on port 21, or any high port (for passive connections), or your accessors use vulnerable systems connected to the internet, I would surely take a look and monitor this file for attempts to pass unwanted files. In that case I suggest to make the login directory of the account READONLY, and create directories for each user or group to write files. Don't use names as 'Upload', 'tmp', and other trivial names. This will not absolutely secure the location, but automated scripts (often used to plant malware) and malware on PC's (rootkits, for instance) will be frustarted ;)