My old OpenVMS server had been replaced with a new server.
I need to run parallel the same application for some time on both
machine. With exception that the old server will not send out files via
FTP to the external machines. But the external parties will need to
send in updated sales file to both VMS servers.

Both machine had been sync with identical OS for apps compatibility.

OS: OpenVMS 7.1
Network: UCX 4.1 - ECO 9

What is the best solution to disable outgoing FTP services while allow
incoming FTP services?

Will adding logical symbol "FTP" to redirect FTP command to a false com
script work?

ie FTP == WRITE SYS$OUTPUT "Outgoing FTP service disabled"

How to set another logical to link to the true FTP?

Alternatively, could I simply rename UCX$FTP.EXE or are there some
other executables i had missed?

Sorry I am not good in OpenVMS or DCL, do appreciate if you could
assist me in solving this issue.

Thank you.

Ultra Kiasu wrote:
> What is the best solution to disable outgoing FTP services while allow
> incoming FTP services?

Assuming that ultimate security is not needed and you just want to
prevent casual use, replacing the executable is perhaps the easiest.

To find out exectly which .exe you need to replace, havine one user do
and ftp transfer, and do a SHOW PROC/CONT/ID=xxxxxx for that user's
process, you'll file the exact file name.

You can then write a simple program that writes "Sorry, FTP service is
disabled" and place the new .exe in the place of the old one.

You may also want to test COPY/FTP to ensure that it also fails. (not
sure if that command is available at your VMS version).

You also need to be careful if you upgrade any software on the machine
since it may re-instate service, or add something like copy/ftp.


Another option you have is to remove the FTP command from the DCLTABLEs.
You could then give normal users a DCLTABLE.EXE that doesn't have FTP
command, and still have a DCLTABLE_FULL.EXE that you could give to the
system manager who woudl still be able to use the FTP command. (you
assign a dcl table in the authorize utility.

HELP SET COMMAND/DELETE

You can also lookup the VERB utuility on the freware of DECUS archives
which allows you to extract a definition of a command. If your system
has COPY/FTP, you can extrtact the COPY command, edit it to remove the
/FTP parameter and then put it back into the DCLTABLE.

Note that existing processes use the older version of DCLTABLE, so when
you replace a DCLTABE.EXE and re-=install it, only new users get the new
version, existing processes still have the old one.

UCX allows you to configure the FTP server (inbound) and client (outbound)
separately.

You need to invoke the sys$manager:UCX$CONFIG.com procedure
(TCPIP$CONFIG.com in 5.0 and later versions) and disable FTP Client
service, while enabling the FTP Server service.

Option 2 is Client Services
Option 3 is Server Services
(iirc)
and FTP is shown as an item in each of the resulting menus


"Ultra Kiasu" <ultrakiasu@hotmail.com> wrote in message
news:1113528427.546955.74680@l41g2000cwc.googlegroups.com...
> My old OpenVMS server had been replaced with a new server.
> I need to run parallel the same application for some time on both
> machine. With exception that the old server will not send out files via
> FTP to the external machines. But the external parties will need to
> send in updated sales file to both VMS servers.
>
> Both machine had been sync with identical OS for apps compatibility.
>
> OS: OpenVMS 7.1
> Network: UCX 4.1 - ECO 9
>
> What is the best solution to disable outgoing FTP services while allow
> incoming FTP services?
>
> Will adding logical symbol "FTP" to redirect FTP command to a false com
> script work?
>
> ie FTP == WRITE SYS$OUTPUT "Outgoing FTP service disabled"
>
> How to set another logical to link to the true FTP?
>
> Alternatively, could I simply rename UCX$FTP.EXE or are there some
> other executables i had missed?
>
> Sorry I am not good in OpenVMS or DCL, do appreciate if you could
> assist me in solving this issue.
>
> Thank you.
>

Sympatico wrote:
> UCX allows you to configure the FTP server (inbound) and client (outbound)
> separately.
> 
> You need to invoke the sys$manager:UCX$CONFIG.com procedure
> (TCPIP$CONFIG.com in 5.0 and later versions) and disable FTP Client
> service, while enabling the FTP Server service.
> 
> Option 2 is Client Services
> Option 3 is Server Services
> (iirc)
> and FTP is shown as an item in each of the resulting menus
> 
> 
> "Ultra Kiasu" <ultrakiasu@hotmail.com> wrote in message
> news:1113528427.546955.74680@l41g2000cwc.googlegroups.com...
> 
>>My old OpenVMS server had been replaced with a new server.
>>I need to run parallel the same application for some time on both
>>machine. With exception that the old server will not send out files via
>>FTP to the external machines. But the external parties will need to
>>send in updated sales file to both VMS servers.
>>
>>Both machine had been sync with identical OS for apps compatibility.
>>
>>OS: OpenVMS 7.1
>>Network: UCX 4.1 - ECO 9
>>
>>What is the best solution to disable outgoing FTP services while allow
>>incoming FTP services?
>>
>>Will adding logical symbol "FTP" to redirect FTP command to a false com
>>script work?
>>
>>ie FTP == WRITE SYS$OUTPUT "Outgoing FTP service disabled"
>>
>>How to set another logical to link to the true FTP?
>>
>>Alternatively, could I simply rename UCX$FTP.EXE or are there some
>>other executables i had missed?
>>

If you need tighter security, you'll need a firewall to block outbound
connections to port 21, because someone could write their own FTP client
and bypass whatever you do to the standard FTP client to disable it.
(Or they could install a program with a built-in FTP client, like
Mozilla.)

>>Sorry I am not good in OpenVMS or DCL, do appreciate if you could
>>assist me in solving this issue.
>>
>>Thank you.
>>


-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

I had used the UCX$CONFIG to disable the FTP Client.

But after having it disabled, I still can use FTP command to ftp out of
my machine.
Did I miss anything? I did not conduct a machine reboot.

Will a reboot help? I won't wish to request for a reboot if it doesn't
help.
Getting a downtime is rather difficult during the testing parallel run
phrase.
But If it is a must, I will request for one.

Any help?

Thanks.

I had used the UCX$CONFIG to disable the FTP Client.

But after having it disabled, I still can use FTP command to ftp out of
my machine.
Did I miss anything? I did not conduct a machine reboot.

Will a reboot help? I won't wish to request for a reboot if it doesn't
help.
Getting a downtime is rather difficult during the testing parallel run
phrase.
But If it is a must, I will request for one.

Any help?

Thanks.

In article <42610c85$1@NEWS.LANGSTOEGER.AT>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes:
> In article <1113645184.774894.173010@o13g2000cwo.googlegroups.com>, "Ultra Kiasu" <ultrakiasu@hotmail.com> writes:
>>I had used the UCX$CONFIG to disable the FTP Client.
>>
>>But after having it disabled, I still can use FTP command to ftp out of
>>my machine.
>>Did I miss anything? I did not conduct a machine reboot.
> 
> No, you only miss the fact, that you can't really disable the (FTP) client.
> All TCPIP/UCX does with disabling the FTP_CLIENT is
> not installing the image sharable (a performance issue for mulituser) and
> not defining the OPENVMS$FTP* logicals for COPY/FTP and DIR/FTP (but still
> misses DELETE/FTP) so that these commands won't directly work.
> 
> But the user can
> 1) still use the TCPIP$FTP_CLIENT.EXE (via the DCL verb FTP)
> 2) still use COPY/FTP and DELETE/FTP (via defining the missing logicals itself)
> 3) still use a private FTP client exe copied from somewhere
> 4) still use a browser with a ftp client within
> 5) still use a selfwritten FTP client
> 
> You could try IP security be blocking outgoing requests _to_ TCP port 21,
> but then the user is still able to access a remote FTP server via
> eg. a browser and a proxy server.
> 
> Better forget the idea. You can make it more difficult, but not prevent it.
> What are to trying to accomplish ?

It sounds like an attempt to achieve DECnet levels of security using IP.
That is not viable in a protocol stack which defaults to no authentication.

In article <1113645184.774894.173010@o13g2000cwo.googlegroups.com>, "Ultra Kiasu" <ultrakiasu@hotmail.com> writes:
>I had used the UCX$CONFIG to disable the FTP Client.
>
>But after having it disabled, I still can use FTP command to ftp out of
>my machine.
>Did I miss anything? I did not conduct a machine reboot.

No, you only miss the fact, that you can't really disable the (FTP) client.
All TCPIP/UCX does with disabling the FTP_CLIENT is
not installing the image sharable (a performance issue for mulituser) and
not defining the OPENVMS$FTP* logicals for COPY/FTP and DIR/FTP (but still
misses DELETE/FTP) so that these commands won't directly work.

But the user can
1) still use the TCPIP$FTP_CLIENT.EXE (via the DCL verb FTP)
2) still use COPY/FTP and DELETE/FTP (via defining the missing logicals itself)
3) still use a private FTP client exe copied from somewhere
4) still use a browser with a ftp client within
5) still use a selfwritten FTP client

You could try IP security be blocking outgoing requests _to_ TCP port 21,
but then the user is still able to access a remote FTP server via
eg. a browser and a proxy server.

Better forget the idea. You can make it more difficult, but not prevent it.
What are to trying to accomplish ?

-- 
Peter "EPLAN" LANGSTOEGER
Network and OpenVMS system specialist
E-mail  peter@langstoeger.at
A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist

Another simpler way to disable outgoing FTP is simply to set the
security of the executable file in SYS$SYSTEM so that "world" cannot
read or execute the file. 

System amangers could still run FTP, but others would get a nasty
message when they attempt to run FTP.

Also, after you have use the configuration procedure to shut down the
FTP client, you need to go to the INSTALL utility and

INSTALL> DELETE SYS$SYSTEM:UCX$FTP_CLIENT.EXE  

(of whatever the exact name of the executable is for your version of
software). This will instantly remove the entry (but not the file). And
you then do not need to reboot.

(note that the UCX configuration utility may have done this for you. You
can use:

INSTALL> LIST SYS$SYSTEM:UCX$FTP_CLIENT.EXE (or whatever the exact file
name is) to see if it is still a known image.

In article <oECVpaeXY2Dl@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>In article <42610c85$1@NEWS.LANGSTOEGER.AT>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes:
>> Better forget the idea. You can make it more difficult, but not prevent it.
>> What are to trying to accomplish ?
>
>It sounds like an attempt to achieve DECnet levels of security using IP.
>That is not viable in a protocol stack which defaults to no authentication.

What DECnet security ? The NETMBX privilege ?

If I think over it, there might be a way to disable access to FTP_CLIENT
How about restricting access to the BG0: device (eg. with ACLs) for all I/O?

Like
$ SET SECU/OBJ=DEV/ACL=((ID=IP_ALLOW,ACC=R,W,L,P),(ID=*,ACC=NONE)) BG0:

And then granting the IP_ALLOW identifier to users allowed to do IP, any IP.
Would that work ?

btw: Is NETMBX required for use of TCPIP ?
If not, how about restricting TCPIP to its usage ?

-- 
Peter "EPLAN" LANGSTOEGER
Network and OpenVMS system specialist
E-mail  peter@langstoeger.at
A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist

In article <1113671128.3bb80dcee0fca9da3bc4050b02ced673@teranews>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>Another simpler way to disable outgoing FTP is simply to set the
>security of the executable file in SYS$SYSTEM so that "world" cannot
>read or execute the file. 

No. It would prevent access to the FTP client of TCPIP only.
There are a lot more ways to run an FTP client on the machine then.
CSWB, FETCH_HTTP (?), LYNX, MOSAIC, MOZILLA, NETSCAPE, WGET, ...

>Also, after you have use the configuration procedure to shut down the
>FTP client, you need to go to the INSTALL utility and
>
>INSTALL> DELETE SYS$SYSTEM:UCX$FTP_CLIENT.EXE  
>
>(of whatever the exact name of the executable is for your version of
>software). This will instantly remove the entry (but not the file). And
>you then do not need to reboot.

The TCPIP$FTP_CLIENT_SHUTDOWN.COM which is run by TCPIP$CONFIG.COM in such
a case (and in case of a shutdown) does deinstall the image.
So, no need to do it yourself...

>(note that the UCX configuration utility may have done this for you. You
>can use:
>
>INSTALL> LIST SYS$SYSTEM:UCX$FTP_CLIENT.EXE (or whatever the exact file
>name is) to see if it is still a known image.

As the image is only installed /OPEN/HEADER/SHARED, I see no need to
deinstall it for (the idea of) a security reason at all.

-- 
Peter "EPLAN" LANGSTOEGER
Network and OpenVMS system specialist
E-mail  peter@langstoeger.at
A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist

In article <42616d11$1@NEWS.LANGSTOEGER.AT>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes:
> In article <oECVpaeXY2Dl@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>>In article <42610c85$1@NEWS.LANGSTOEGER.AT>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes:
>>> Better forget the idea. You can make it more difficult, but not prevent it.
>>> What are to trying to accomplish ?
>>
>>It sounds like an attempt to achieve DECnet levels of security using IP.
>>That is not viable in a protocol stack which defaults to no authentication.
> 
> What DECnet security ? The NETMBX privilege ?

That is the one particularly relevant to this case.

Another important one is the requirement for privilege to set up a
service that can accept incoming connections without authentication.

> If I think over it, there might be a way to disable access to FTP_CLIENT
> How about restricting access to the BG0: device (eg. with ACLs) for all I/O?
> 
> Like
> $ SET SECU/OBJ=DEV/ACL=((ID=IP_ALLOW,ACC=R,W,L,P),(ID=*,ACC=NONE)) BG0:
> 
> And then granting the IP_ALLOW identifier to users allowed to do IP, any IP.
> Would that work ?
> 
> btw: Is NETMBX required for use of TCPIP ?
> If not, how about restricting TCPIP to its usage ?