Restricting Access to TCP/IP and DECnet - VMS

This is a discussion on Restricting Access to TCP/IP and DECnet - VMS ; In article , Tad Winters writes: >Jim Duff wrote in >news:47a0707e$1@dnews.tpgi.com.au: > >> Bob Gezelter wrote: >>> On Jan 29, 6:58 pm, "Robert Jarratt" wrote: >>>> Is it possible to restrict access to TCP/IP (5.1) and DECnet (IV) >>>> on ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 36 of 36

Thread: Restricting Access to TCP/IP and DECnet

  1. Re: Restricting Access to TCP/IP and DECnet

    In article , Tad Winters writes:
    >Jim Duff wrote in
    >news:47a0707e$1@dnews.tpgi.com.au:
    >
    >> Bob Gezelter wrote:
    >>> On Jan 29, 6:58 pm, "Robert Jarratt" wrote:
    >>>> Is it possible to restrict access to TCP/IP (5.1) and DECnet (IV)
    >>>> on a per-user basis? In other words I would like someone to be
    >>>> able to access my machine, but not to go from that machine to
    >>>> anywhere else on the network.
    >>>>
    >>>> Thanks
    >>>>
    >>>> Rob
    >>>
    >>> Rob,
    >>>
    >>> WADU, I will have to disagree with Jim Duff. Restricting access to
    >>> particular images is a good idea, but since these are essentially
    >>> non- privileged images, a (somewhat) inventive user can circumvent
    >>> the security by finding and using copies of the images or
    >>> equivalent from his own directory.
    >>> [snip]

    >>
    >> How is the user going to get a copy of the executable if it is
    >> marked ACCESS=NONE?
    >>
    >> Jim

    >
    >It occurs to me that the user's account could have the disimage flag set
    >and also have a customized version of DCLTABLES, which did not include
    >the necessary commands to either make an outbound connection or further
    >update the process copy of the command tables to add such access.


    Correct. That's been done in the past to restricted accounts to restrict
    the user(s) to only that which they are _required_ to do to perform their
    work and functions.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    "Well my son, life is like a beanstalk, isn't it?"

    http://tmesis.com/drat.html

  2. Re: Restricting Access to TCP/IP and DECnet


    "Bob Koehler" wrote in message
    news:+qIY+3VhprSS@eisner.encompasserve.org...
    > In article , "Robert Jarratt"
    > writes:
    >>
    >> Thanks for all the replies. A few people have pointed out that my
    >> question
    >> is not entirely clear. The reason I want to do this is that I want to
    >> give
    >> an acquaintance access to my hobbyist VAX. I have opened up telnet access
    >> to
    >> it from the internet, but the machine is on my home network and just to
    >> be
    >> safe I would rather he be unable to go anywhere else on the home network,
    >> including back out on to the internet. I suppose I could put the machine
    >> in
    >> a DMZ if I was doing this properly, but my firewall server only has 2
    >> nics
    >> at the moment.
    >>
    >> I will remove NETMBX and see if that does the trick.

    >
    > You've asked about TELNET and DECnet, are you running any other
    > protocols, such as LAT, that you might need to block? (I assume the
    > system is not part of a cluster).


    Yes I have LAT but normally I do not have other systems switched on so there
    would be nowhere to go with it.

    Regards

    Rob



  3. Re: Restricting Access to TCP/IP and DECnet


    "IanMiller" wrote in message
    news:38bcdfed-8c7d-479c-880c-338c15eb18d0@s19g2000prg.googlegroups.com...
    > Note that allowing telnet means a valid username & password for your
    > systems are travelling over the internet unencrypted.
    >


    Yes I know that, but I am prepared to accept that risk. That said, what
    alternatives do you suggest?

    Regards

    Rob



  4. Re: Restricting Access to TCP/IP and DECnet

    On Jan 31, 4:49 pm, "Robert Jarratt" wrote:
    > "IanMiller" wrote in message
    >
    > news:38bcdfed-8c7d-479c-880c-338c15eb18d0@s19g2000prg.googlegroups.com...
    >
    > > Note that allowing telnet means a valid username & password for your
    > > systems are travelling over the internet unencrypted.

    >
    > Yes I know that, but I am prepared to accept that risk. That said, what
    > alternatives do you suggest?
    >
    > Regards
    >
    > Rob


    Rob,

    With LAT, I would first consider disabling OUTGOING connections. See
    the HELP text within LATCP. If outbound is enabled, I would fix the
    setup commands in SYS$MANAGER_LAT$SYSTARTUP.COM.

    If you need outbound connections, I would consider looking into the
    ACL idea that I mentioned earlier in this thread.

    - Bob Gezelter, http://www.rlgsc.com

  5. Re: Restricting Access to TCP/IP and DECnet

    In article , "Robert Jarratt" writes:
    >
    > Yes I know that, but I am prepared to accept that risk. That said, what
    > alternatives do you suggest?


    Why not SSH?


  6. Re: Restricting Access to TCP/IP and DECnet


    "Bob Koehler" wrote in message
    news:LOMDmdo5hR1B@eisner.encompasserve.org...
    > In article , "Robert Jarratt"
    > writes:
    >>
    >> Yes I know that, but I am prepared to accept that risk. That said, what
    >> alternatives do you suggest?

    >
    > Why not SSH?
    >


    I have the TCP/IP version that comes with VMS 7.3, as far as I can tell this
    does not have SSH.

    Regards

    Rob



  7. Re: Restricting Access to TCP/IP and DECnet

    It happens that Robert Jarratt formulated :
    > "Bob Koehler" wrote in message
    > news:LOMDmdo5hR1B@eisner.encompasserve.org...
    >> In article , "Robert Jarratt"
    >> writes:
    >>>
    >>> Yes I know that, but I am prepared to accept that risk. That said, what
    >>> alternatives do you suggest?

    >>
    >> Why not SSH?
    >>

    >
    > I have the TCP/IP version that comes with VMS 7.3, as far as I can tell this
    > does not have SSH.
    >
    > Regards
    >
    > Rob


    We have it with Alpha V7.3-2. I however do not know whether it came in
    the box or was downloaded later. Works like a charm, we're thinking
    about disabling Telnet.

    --
    Marc Van Dyck



  8. Re: Restricting Access to TCP/IP and DECnet

    In article , "Robert Jarratt" writes:
    > Xref: news.binc.net comp.os.vms:391593
    >
    >
    > "Bob Koehler" wrote in message
    > news:LOMDmdo5hR1B@eisner.encompasserve.org...
    >> In article , "Robert Jarratt"
    >> writes:
    >>>
    >>> Yes I know that, but I am prepared to accept that risk. That said, what
    >>> alternatives do you suggest?

    >>
    >> Why not SSH?
    >>

    >
    > I have the TCP/IP version that comes with VMS 7.3, as far as I can tell this
    > does not have SSH.


    Aha. I use Multinet and have SSH all the way back to my 5.x systems.

    You can get SSH separately from Process and run that on top of TCP/IP
    Services.

    Or, if this is a hobbyist system, you can just get al lof Multinet
    and dump TCP/IP Services.


  9. Re: Restricting Access to TCP/IP and DECnet

    Robert Jarratt wrote:
    > "Bob Koehler" wrote in message
    > news:LOMDmdo5hR1B@eisner.encompasserve.org...
    >> In article , "Robert Jarratt"
    >> writes:
    >>> Yes I know that, but I am prepared to accept that risk. That said, what
    >>> alternatives do you suggest?

    >> Why not SSH?

    >
    > I have the TCP/IP version that comes with VMS 7.3, as far as I can tell this
    > does not have SSH.


    You could get a freeware SSH Daemon and SSH client for
    that DEC TCP/IP as well.

    Arne

  10. Re: Restricting Access to TCP/IP and DECnet


    "Arne Vajh°j" wrote in message
    news:47a3bfea$0$90265$14726298@news.sunsite.dk...
    > Robert Jarratt wrote:
    >> "Bob Koehler" wrote in message
    >> news:LOMDmdo5hR1B@eisner.encompasserve.org...
    >>> In article , "Robert Jarratt"
    >>> writes:
    >>>> Yes I know that, but I am prepared to accept that risk. That said, what
    >>>> alternatives do you suggest?
    >>> Why not SSH?

    >>
    >> I have the TCP/IP version that comes with VMS 7.3, as far as I can tell
    >> this does not have SSH.

    >
    > You could get a freeware SSH Daemon and SSH client for
    > that DEC TCP/IP as well.
    >
    > Arne


    Do you have any suggestions for a good freeware implementation?

    Thanks

    Rob



  11. Re: Restricting Access to TCP/IP and DECnet

    Robert Jarratt wrote:
    > "Arne Vajh°j" wrote in message
    > news:47a3bfea$0$90265$14726298@news.sunsite.dk...
    >> Robert Jarratt wrote:
    >>> "Bob Koehler" wrote in message
    >>> news:LOMDmdo5hR1B@eisner.encompasserve.org...
    >>>> In article , "Robert Jarratt"
    >>>> writes:
    >>>>> Yes I know that, but I am prepared to accept that risk. That said, what
    >>>>> alternatives do you suggest?
    >>>> Why not SSH?
    >>> I have the TCP/IP version that comes with VMS 7.3, as far as I can tell
    >>> this does not have SSH.

    >> You could get a freeware SSH Daemon and SSH client for
    >> that DEC TCP/IP as well.

    >
    > Do you have any suggestions for a good freeware implementation?


    I have used the DECThreads SSH server and the Fish client. They
    work fine.

    The code is almost 10 years old, so they are not uptodate
    with everything, but they should still be better than telnet ...

    Arne

  12. Re: Restricting Access to TCP/IP and DECnet

    PacoLinux wrote:
    (snip)

    >>>Is it possible to restrict access to TCP/IP (5.1) and DECnet (IV) on a
    >>>per-user basis? In other words I would like someone to be able to access my
    >>>machine, but not to go from that machine to anywhere else on the network.

    (snip)

    > -> I'm not aware of a way to do this in UN*X, either, without breaking
    > -> almost the entire system.


    > You can use a restricted shell :
    > http://www.gnu.org/software/bash/man...stricted-Shell


    I believe it can be done with the restricted shell, but it still isn't easy.

    You have to give the user a read only directory, otherwise executable files
    can be loaded and executed. I believe rsh restricts cd and the ability to
    execute files by path, such as /tmp/xyz.

    You then need to supply commands that do what the user is supposed to
    be allowed to do. chroot helps a lot, too.

    -- glen


  13. Re: Restricting Access to TCP/IP and DECnet

    glen herrmannsfeldt skrev:
    > PacoLinux wrote:
    > (snip)
    >
    >>>> Is it possible to restrict access to TCP/IP (5.1) and DECnet (IV) on a
    >>>> per-user basis? In other words I would like someone to be able to
    >>>> access my
    >>>> machine, but not to go from that machine to anywhere else on the
    >>>> network.

    > (snip)
    >
    >> -> I'm not aware of a way to do this in UN*X, either, without breaking
    >> -> almost the entire system.

    >
    >> You can use a restricted shell :
    > >

    > http://www.gnu.org/software/bash/man...stricted-Shell
    >
    > I believe it can be done with the restricted shell, but it still isn't
    > easy.
    >
    > You have to give the user a read only directory, otherwise executable files
    > can be loaded and executed. I believe rsh restricts cd and the ability to
    > execute files by path, such as /tmp/xyz.
    >
    > You then need to supply commands that do what the user is supposed to
    > be allowed to do. chroot helps a lot, too.


    I havaen't seen the start of this, but in VMS, shouldn't just not having TMPMBX
    solve this? Is there something else you might want to run that requires TMPMBX?

    Johnny

    --
    Johnny Billquist || "I'm on a bus
    || on a psychedelic trip
    email: bqt@softjar.se || Reading murder books
    pdp is alive! || tryin' to stay hip" - B. Idol

  14. Re: Restricting Access to TCP/IP and DECnet

    In article , Johnny Billquist writes:
    >glen herrmannsfeldt skrev:
    >> PacoLinux wrote:
    >> (snip)
    >>
    >>>>> Is it possible to restrict access to TCP/IP (5.1) and DECnet (IV) on a
    >>>>> per-user basis? In other words I would like someone to be able to
    >>>>> access my
    >>>>> machine, but not to go from that machine to anywhere else on the
    >>>>> network.

    >> (snip)
    >>
    >>> -> I'm not aware of a way to do this in UN*X, either, without breaking
    >>> -> almost the entire system.

    >>
    >>> You can use a restricted shell :
    >> >

    >> http://www.gnu.org/software/bash/man...stricted-Shell
    >>
    >> I believe it can be done with the restricted shell, but it still isn't
    >> easy.
    >>
    >> You have to give the user a read only directory, otherwise executable files
    >> can be loaded and executed. I believe rsh restricts cd and the ability to
    >> execute files by path, such as /tmp/xyz.
    >>
    >> You then need to supply commands that do what the user is supposed to
    >> be allowed to do. chroot helps a lot, too.

    >
    >I havaen't seen the start of this, but in VMS, shouldn't just not having TMPMBX
    >solve this? Is there something else you might want to run that requires TMPMBX?


    Remove TMPMBX? No! Take away the NETMBX privilege. TMPMBX privilege
    is needed to do some basic things such as SPAWN and PIPE. If these are
    features (and some others) that are not needed then by all means limit
    TMPMBX privilege too. However, the lack of TMPMBX will not limit DECnet
    and TCP/IP.


    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    .... pejorative statements of opinion are entitled to constitutional protection
    no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

    Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    of usenet _must_ include its contents in its entirety including this copyright
    notice, disclaimer and quotations.

  15. Re: Restricting Access to TCP/IP and DECnet

    Johnny Billquist wrote:
    > glen herrmannsfeldt skrev:
    >> PacoLinux wrote:
    >> (snip)
    >>
    >>>>> Is it possible to restrict access to TCP/IP (5.1) and DECnet (IV) on a
    >>>>> per-user basis? In other words I would like someone to be able to
    >>>>> access my
    >>>>> machine, but not to go from that machine to anywhere else on the
    >>>>> network.

    >> (snip)
    >>
    >>> -> I'm not aware of a way to do this in UN*X, either, without breaking
    >>> -> almost the entire system.

    >>
    >>> You can use a restricted shell :
    >> >

    >> http://www.gnu.org/software/bash/man...stricted-Shell
    >>
    >> I believe it can be done with the restricted shell, but it still isn't
    >> easy.
    >>
    >> You have to give the user a read only directory, otherwise executable
    >> files
    >> can be loaded and executed. I believe rsh restricts cd and the
    >> ability to
    >> execute files by path, such as /tmp/xyz.
    >>
    >> You then need to supply commands that do what the user is supposed to
    >> be allowed to do. chroot helps a lot, too.

    >
    > I havaen't seen the start of this, but in VMS, shouldn't just not having
    > TMPMBX solve this? Is there something else you might want to run that
    > requires TMPMBX?
    >
    > Johnny
    >


    Did you, by chance, mean NETMBX?

  16. Re: Restricting Access to TCP/IP and DECnet

    Richard B. Gilbert skrev:
    > Johnny Billquist wrote:
    >> glen herrmannsfeldt skrev:
    >>> PacoLinux wrote:
    >>> (snip)
    >>>
    >>>>>> Is it possible to restrict access to TCP/IP (5.1) and DECnet (IV)
    >>>>>> on a
    >>>>>> per-user basis? In other words I would like someone to be able to
    >>>>>> access my
    >>>>>> machine, but not to go from that machine to anywhere else on the
    >>>>>> network.
    >>> (snip)
    >>>
    >>>> -> I'm not aware of a way to do this in UN*X, either, without breaking
    >>>> -> almost the entire system.
    >>>
    >>>> You can use a restricted shell :
    >>> >
    >>> http://www.gnu.org/software/bash/man...stricted-Shell
    >>>
    >>>
    >>> I believe it can be done with the restricted shell, but it still
    >>> isn't easy.
    >>>
    >>> You have to give the user a read only directory, otherwise executable
    >>> files
    >>> can be loaded and executed. I believe rsh restricts cd and the
    >>> ability to
    >>> execute files by path, such as /tmp/xyz.
    >>>
    >>> You then need to supply commands that do what the user is supposed to
    >>> be allowed to do. chroot helps a lot, too.

    >>
    >> I havaen't seen the start of this, but in VMS, shouldn't just not
    >> having TMPMBX solve this? Is there something else you might want to
    >> run that requires TMPMBX?
    >>
    >> Johnny
    >>

    >
    > Did you, by chance, mean NETMBX?


    Probably yes. :-)

    Johnny


    --
    Johnny Billquist || "I'm on a bus
    || on a psychedelic trip
    email: bqt@softjar.se || Reading murder books
    pdp is alive! || tryin' to stay hip" - B. Idol

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2