Restricting Access to TCP/IP and DECnet - VMS

This is a discussion on Restricting Access to TCP/IP and DECnet - VMS ; 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 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 36

Thread: Restricting Access to TCP/IP and DECnet

  1. Restricting Access to TCP/IP and DECnet

    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



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

    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.


    I guess it depends what you mean by "access".

    If you mean command line, you've got a lot of work to do customizing a
    user-specific version of DCLTABLES.

    If you mean log in, select from a (DCL) menu and/or logout, then read up
    on captive accounts.

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

    David J Dachtera
    DJE Systems

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

    On Jan 29, 2008 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.


    If I remember correctly, a user needs the NETMBX privilege to use
    DECnet (I'm not sure about TCP/IP). Take that away and I believe they
    can't use DECnet.

    Ken

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

    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
    >
    >


    As David said else-thread, it depends on what you mean by "restrict
    access". Assuming you will allow them to e-mail and use other services
    on the machine you give them access to, and you just want to restrict
    them from telnet/ssh/set host to other machines:

    Create an identifier (for example, RESTRICT_NETWORK) and grant it to the
    user. Then create an access control list on SYS$SYSTEM:RTPAD.EXE,
    SYS$SYSTEM:TCPIP$TELNET.EXE, and SYS$SYSTEM:TCPIP$SSH_SSH2.EXE to grant
    ACCESS=NONE to the RESTRICT_NETWORK identifier.

    You may need to add this ACL to other images depending on what you have
    configured (e.g., LAT, RLOGIN, etc).

    HTH,
    Jim
    --
    www.eight-cubed.com

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

    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. It sounds effective, but can be circumvented
    without raising any security alarms, which is a "very bad thing".

    However, I do agree with Ken Robinson's comment about NETMBX. Removing
    NETMBX is completely safe, and cannot be circumvented from the user
    side of the table. There is no substitute. A spot check (TCPIP 5.5)
    shows that NETMBX is required to open a socket (Cautionary note: I
    have not checked older documentation for verification, and a check of
    an older version of Multinet seems to indicate that this check has not
    been universal among TCP/IP stacks).

    Another possibility is to put an ACL on the pseudo device used by
    TCPIP to access the ACP. I have not looked into this approach in
    depth, but in concept it should be airtight. I would recommend caution
    before implementing it as always, one may find a longer list of
    processes (and accounts) need access to TCPIP than is appreciated at
    first glance.

    I hope that the above is helpful, if I have been unclear, please let
    me know.

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

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

    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
    --
    www.eight-cubed.com

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

    On Jan 30, 2:23 am, David J Dachtera
    wrote:
    > 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.

    >
    > I guess it depends what you mean by "access".
    >
    > If you mean command line, you've got a lot of work to do customizing a
    > user-specific version of DCLTABLES.
    >
    > If you mean log in, select from a (DCL) menu and/or logout, then read up
    > on captive accounts.
    >
    > I'm not aware of a way to do this in UN*X, either, without breaking
    > almost the entire system.
    >
    > David J Dachtera
    > DJE Systems


    -> 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

    Paco

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

    On Jan 30, 7:41*am, Jim Duff wrote:
    > How is the user going to get a copy of the executable if it is marked
    > ACCESS=NONE?
    >
    > Jim


    From a different OpenVMS system where that user does not have
    restricted access. File transfer by FTP or FAL would not be
    restricted in your solution.

    In a general sense, you're not concerned about users that play by the
    rules. It's the ones that will attempt to circumvent the security
    restrictions that you need to worry about. So, you have to think
    about other possible ways of getting a working executable onto the
    system and close those avenues as well.

    Removing NETMBX should do the trick, with the caveat that other
    functionality may be impacted as well.

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

    FrankS wrote:

    > Removing NETMBX should do the trick, with the caveat that other
    > functionality may be impacted as well.


    You can always grant those applications NETMBX privilege so that users
    without netmbx can still use that one application.

    If you are concerned about remote users downloading files from the
    secure system to their system, you also need to worry about programs
    such as kermit that don't need netmbx because they use the existing
    "serial line" link back to the remote user. So a user could
    theoretically download files to/from with a serial connection file
    transfer. And there is extremely little you can do to prevent this,
    short of preventing creation of files on the system. (thus preventing
    them from downloading a stub that allows them to download the kermit
    executable).

    It really depends on how paranoid you want to be.

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

    Jim Duff wrote:

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


    From his own "home" system or any other system he can have access to
    and transfer it to the target system.

    Of course, he would need some network tool to transfer it, but there
    might be cut'n'paste and DCL share (IIRC) or UUDECODE or Kermit or...

    He might even have access to a compiler and write his own tool ;-)

    Albrecht

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

    On Jan 30, 2:25 pm, JF Mezei wrote:
    > FrankS wrote:
    > > Removing NETMBX should do the trick, with the caveat that other
    > > functionality may be impacted as well.

    >
    > You can always grant those applications NETMBX privilege so that users
    > without netmbx can still use that one application.
    >
    > If you are concerned about remote users downloading files from the
    > secure system to their system, you also need to worry about programs
    > such as kermit that don't need netmbx because they use the existing
    > "serial line" link back to the remote user. So a user could
    > theoretically download files to/from with a serial connection file
    > transfer. And there is extremely little you can do to prevent this,
    > short of preventing creation of files on the system. (thus preventing
    > them from downloading a stub that allows them to download the kermit
    > executable).
    >
    > It really depends on how paranoid you want to be.


    -> If you are concerned about remote users downloading files from the
    -> secure system to their system,

    You can always download/upload a file to your host via cut/paste -
    binary files uuencoded previously -

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

    On Jan 30, 7:41 am, Jim Duff wrote:
    > 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
    > --www.eight-cubed.com


    Jim,

    The comments that have been posted in the interim have mentioned
    several various approaches that concern me.

    Preventing access to executables has its utility, but it presumes that
    the users being secured against have no capability of getting
    executables on their own power.

    From an auditing perspective, it is a far surer thing to prohibit
    access to the device that serves as a mandatory gateway to the TCP/IP
    stack (or to remove NETMBX, after verification that it is indeed
    needed for ALL network accesses), than to say "Well, I have blocked
    access to known network utilities". Blocking access to utilities is
    akin to applications level controls, they have some utility, but they
    are not airtight in the face of user belligerence, which is what
    security measures are intended to prevent.

    The recent high profile scandal at Societe General, which has been
    reported widely (see http://www.nytimes.com/2008/01/29/bu.../29trader.html
    an article in The New York Times), clearly points out that security
    and audit controls exist for the purpose of preventing deliberate
    misuse, not casual accidents.

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

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

    In article <7dd80f60801291736h7b0673ffrf9c149fa2048c5c6@mail.g mail.com>, "Ken Robinson" writes:
    > On Jan 29, 2008 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.

    >
    > If I remember correctly, a user needs the NETMBX privilege to use
    > DECnet (I'm not sure about TCP/IP). Take that away and I believe they
    > can't use DECnet.


    Ken is correct. Note that a restriction to prevent inbound DECnet
    access would be via the REMOTE (interactive) and NETWORK (program)
    access controls in SYSUAF. If those are enabled, lack of NETMBX
    privilege can prevent outbound connections.

    Considering the recent discussions of HP TCPIP not respecting the
    breakin evasion protocol, I will not venture a guess on whether
    TCPIP works as documented in your area of interest.

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

    Bob Gezelter wrote:
    > On Jan 30, 7:41 am, Jim Duff wrote:
    >> 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
    >> --www.eight-cubed.com

    >
    > Jim,
    >
    > The comments that have been posted in the interim have mentioned
    > several various approaches that concern me.
    >
    > Preventing access to executables has its utility, but it presumes that
    > the users being secured against have no capability of getting
    > executables on their own power.
    >
    > From an auditing perspective, it is a far surer thing to prohibit
    > access to the device that serves as a mandatory gateway to the TCP/IP
    > stack (or to remove NETMBX, after verification that it is indeed
    > needed for ALL network accesses), than to say "Well, I have blocked
    > access to known network utilities". Blocking access to utilities is
    > akin to applications level controls, they have some utility, but they
    > are not airtight in the face of user belligerence, which is what
    > security measures are intended to prevent.
    >
    > [snip]



    OK, I'm paranoid. But am I paranoid *enough*?

    ;-)

    --
    www.eight-cubed.com

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


    "Robert Jarratt" wrote in message
    news:S4Pnj.34169$a61.25452@newsfe3-win.ntli.net...
    > 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
    >


    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.

    Thanks

    Rob



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


    "Robert Jarratt" wrote in message
    news:d65oj.6703$L73.3723@newsfe1-win.ntli.net...
    >
    > "Robert Jarratt" wrote in message
    > news:S4Pnj.34169$a61.25452@newsfe3-win.ntli.net...
    >> 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
    >>

    >
    > 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.
    >
    > Thanks
    >
    > Rob
    >


    For the record, I have just tried removing NETMBX and it does what I want. I
    tried ping, telnet out, ftp, and set host, none of these worked after
    removing netmbx.

    Thanks all

    Rob



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

    Note that allowing telnet means a valid username & password for your
    systems are travelling over the internet unencrypted.


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

    In article , "Robert Jarratt" writes:
    > 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.


    You can block access to DECnet by making sure the acconut does not
    have NETMBX privilege.

    TCP/IP (I assume ytou mean HP's) I don't know about.


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

    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).

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

    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.

    Tad

+ Reply to Thread
Page 1 of 2 1 2 LastLast