Restricting user access between network interfaces

Restricting user access between network interfaces

Post by Fatu » Fri, 29 Sep 2000 04:00:00



We have a Unix system (HP 9000 running HP-UX 10.01) with two network
interfaces, say (A) and (B). My problem is that we would like to prevent
users who connect  (via telnet) on one interface (A)  from being able to use
the other interface (B) to connect to systems visible on interface (B). We
could remove access to the telnet, ftp etc binaries so that users don't have
the tools neccessary to get off the system at all, but we only wish to
restrict a subset of users (ie those connecting via interface (A)) and not
all users.

Personally I would use a firewall to control such access, but managers here
seem to think it' s possible to do at the system level. I can't see how to
achieve this - anyone out there clever enough to think of a method?

Thanks,
Fatus
--
Fatus

 
 
 

Restricting user access between network interfaces

Post by Jefferson Ogat » Fri, 29 Sep 2000 04:00:00


Why did you set the followups to comp.unix.questions and comp.unix.misc, while
posting the message to comp.unix.admin?

Here's what I posted last night which is now also sitting in those two
newsgroups as an orphaned thread:

----


> We have a Unix system (HP 9000 running HP-UX 10.01) with two network
> interfaces, say (A) and (B). My problem is that we would like to prevent
> users who connect  (via telnet) on one interface (A)  from being able to use
> the other interface (B) to connect to systems visible on interface (B). We
> could remove access to the telnet, ftp etc binaries so that users don't have
> the tools neccessary to get off the system at all, but we only wish to
> restrict a subset of users (ie those connecting via interface (A)) and not
> all users.

> Personally I would use a firewall to control such access, but managers here
> seem to think it' s possible to do at the system level. I can't see how to
> achieve this - anyone out there clever enough to think of a method?

1. Use tcp_wrappers to protect the services on the hosts accessible via B (the
ones you don't want those users to be able to reach), in combination with an
identd running on the HP, to refuse connections initiated by the restricted
users.

2. chroot the restricted access users to an area of the HP filesystem where
they have no network programs, and cannot create executable files. You didn't
say what the restricted users have to be able to do on the HP, so it's not
clear whether this is feasible.

3. Provide a different box for the restricted users to log into.

What firewall configuration did you have in mind that would let you do this?

--
Jefferson Ogata : Internetworker, Antibozo



 
 
 

Restricting user access between network interfaces

Post by pe.. » Fri, 29 Sep 2000 04:00:00



> We have a Unix system (HP 9000 running HP-UX 10.01) with two network
> interfaces, say (A) and (B). My problem is that we would like to prevent
> users who connect  (via telnet) on one interface (A)  from being able to use
> the other interface (B) to connect to systems visible on interface (B). We
> could remove access to the telnet, ftp etc binaries so that users don't have
> the tools neccessary to get off the system at all, but we only wish to
> restrict a subset of users (ie those connecting via interface (A)) and not
> all users.

A user process is not "bound" in any way to a network interface, thus
the task is not possible.

Quote:> Personally I would use a firewall to control such access, but managers here
> seem to think it' s possible to do at the system level. I can't see how to
> achieve this - anyone out there clever enough to think of a method?

Buy some new managers :-) (cheap on ebay i think)

> Thanks,
> Fatus
> --
> Fatus


--
Peter H?kanson        
        IPSec  Sverige      (At the Riverside of Gothenburg, home of Volvo)
           Sorry about my e-mail address, but i'm trying to keep spam out.
           Remove "icke-reklam"and "invalid"  and it works.
 
 
 

Restricting user access between network interfaces

Post by Peter Schmi » Sat, 30 Sep 2000 04:00:00


<snip>

Quote:

> What firewall configuration did you have in mind that would let you do this?

I'm not sure what software is available for HP's but ip-filter is a type of
firewall/packet filter that could do this very easy.

Pete.

> --
> Jefferson Ogata : Internetworker, Antibozo



 
 
 

Restricting user access between network interfaces

Post by Jefferson Ogat » Sat, 30 Sep 2000 04:00:00



> <snip>

> > What firewall configuration did you have in mind that would let you do this?

> I'm not sure what software is available for HP's but ip-filter is a type of
> firewall/packet filter that could do this very easy.

> Pete.

As a long-time user of IP Filter, I'm unaware of how it could do this. Care to
elaborate?

--
Jefferson Ogata : Internetworker, Antibozo


 
 
 

Restricting user access between network interfaces

Post by Fatu » Thu, 05 Oct 2000 04:00:00


Thanks to everyone who's offered advice (and apologies for the incorrect
followup newsgroups - my mistake):



> > We have a Unix system (HP 9000 running HP-UX 10.01) with two network
> > interfaces, say (A) and (B). My problem is that we would like to prevent
> > users who connect  (via telnet) on one interface (A)  from being able to
use
> > the other interface (B) to connect to systems visible on interface (B).
> A user process is not "bound" in any way to a network interface, thus
> the task is not possible.

Yes, that's what I first thought, although there have been some suggestions
of using tcp-wrapper etc. I've not used tcp-wrapper before, although I
thought it was used to restrict access to services for incoming connections;
I need to restrict access out of the system to others connected on interface
B. I may be wrong though, and I'll take a look at tcp-wrapper to see what it
can do.

I guess we can simplify the problem a little, as my wonderful (!) management
team now tell me that we know which user accounts we need to restrict
(rather than anyone coming *in* on a specific net interface) - it doesn't
really matter which network interface the users come in on; what I need is
to restrict a subset of users from connecting to other systems visible on a
specific network interface ( (B) in the original posting.) Can tcp-wrapper,
or any other method, do this? As far as I know (and I'm probably wrong) you
can't say "users x y and z can't use network interface B"... but perhaps
it's possible to say "users x, y and z can't use telnet, ftp etc... at
all"...
Any thoughts?

Quote:

> > Personally I would use a firewall to control such access, but managers
here
> > seem to think it' s possible to do at the system level. I can't see how
to
> > achieve this - anyone out there clever enough to think of a method?

> Buy some new managers :-) (cheap on ebay i think)

Yes, but it's the old ones I really need to get rid of... is there a manager
recycling company out there? ;-)
 
 
 

Restricting user access between network interfaces

Post by James T. Denni » Mon, 09 Oct 2000 04:00:00






>>> We have a Unix system (HP 9000 running HP-UX 10.01) with two network
>>> interfaces, say (A) and (B). My problem is that we would like to
>>> prevent users who connect  (via telnet) on one interface (A)  from
>>> being able to use the other interface (B) to connect to systems
>>> visible on interface (B).
>> A user process is not "bound" in any way to a network interface, thus
>> the task is not possible.

 ...

Quote:> I guess we can simplify the problem a little, as my wonderful (!)
> management team now tell me that we know which user accounts we
> need to restrict (rather than anyone coming *in* on a specific net
> interface) - it doesn't really matter which network interface the
> users come in on; what I need is to restrict a subset of users
> from connecting to other systems visible on a specific network
> interface ( (B) in the original posting.) Can tcp-wrapper, or any
> other method, do this? As far as I know (and I'm probably wrong) you
> can't say "users x y and z can't use network interface B"... but
> perhaps it's possible to say "users x, y and z can't use telnet, ftp
> etc... at all"...
> Any thoughts?
>>> Personally I would use a firewall to control such access, but
>>> managers here seem to think it' s possible to do at the system
>>> level. I can't see how to achieve this - anyone out there clever
>>> enough to think of a method?

 You are basically correct.  You need some proxy software (which
 is presumably what you meant by "firewall").

 Your management are too ignorant to listen to you; and you
 apparently lack the strength of your convictions.  

 I can understand you're wanting to give them a qualified opinion.
 Saying "I'm pretty sure you'd need a proxying package like TIS
 firewall toolkit to do that; but let me check around to see if
 HP has incorporated something like this into their OS" is quite
 reasonable.  It's what I'd do.

 The fact is that I don't know HP-UX.  Maybe HP *has* added some
 proxying control features somewhere into their UNIX.  That have
 (POSIX?) ACLs for files; maybe they added ACLs for TCP/IP ports.

 However, it's unlikely.  Under UNIX there are generally no
 special privileges required for local user processes to bind to
 "unprivileged" TCP and UDP ports.  What your mgt is asking for
 would amount to putting ACLs on unprivileged ports.  I guess
 you could create local packet filters on outbound packets
 (I know that the Linux ipfwadm, and ipchains code allows such
 rules on a per interface basis).  Then you'd have to write
 your own SUID versions of (or wrappers for) the telnet, ftp and
 other clients.  (These would poke holes into the packet filter
 for the duration of the process and close them back up on exit.

 Of course this would entail having a whole bunch of custom
 SUID programs and wrappers.  It might be possible to have them
 SGID or SUID to some psuedo-user; a psuedo-user that's only
 privileged enough to communicate through some channel (UNIX
 domain socket, perhaps) on which a root privileged listens for
 open requests).  However, this still sounds like more than
 you want to do yourself.  

 The custom coding approach entails considerable risk.  You're
 quite likely to implement an agent that fails to enforce your
 policy and is vulnerable to full subversion.  In other words
 it is common to lose more control than you gain when trying to
 write software that interfaces across security contexts  (SUID,
 client/server, etc).

 If the proxy/firewall system is configured to prevent interactive
 (shell) use by the users then the job is somewhat easier.  Software
 already exists to do proxying and authenticated proxying.  If
 the interactive access to the host is required; then you may have
 to recommend interposing an additional applications proxy system
 between it's B interface and the network(s) to which that
 interface connects.

 In either case (whether the host *is* the applications proxy
 or there is an additional one interposed) the next question relates
 to the client side authentication support.  For example, if the
 host *is* the proxy and the clients are MS Window boxes then
 you might have to install some special software on them to
 support the proy's authentication.  Even that would probably
 be somewhat vulnerable (local users can usually hack at
 one another's Windows systems pretty easily; local desktop UNIX
 stations are almost as bad).

 So, I'd look into TIS FWTK (firewall toolkit) or at one of
 of the newer freer packages like Juniper FWTK or even the old
 NEC SOCKS (4 or 5).  It seems that the best that any of these
 offered was ident or simple sniffable passwords.  I thought

 I'd thought I'd heard of a proxy that was wired into Kerberos
 authentication.  That would be ideal; you'd have to authenticate
 into your local Kerberos realm in order to access services on the
 proxy.  However I don't remember a name or keyword and I don't
 see anything on Google! or Yahoo!  Maybe I was dreaming.

 
 
 

1. Restricting user access between network interfaces

1. Use tcp_wrappers to protect the services on the hosts accessible via B (the
ones you don't want those users to be able to reach), in combination with an
identd running on the HP, to refuse connections initiated by the restricted
users.

2. chroot the restricted access users to an area of the HP filesystem where
they have no network programs, and cannot create executable files. You didn't
say what the restricted users have to be able to do on the HP, so it's not
clear whether this is feasible.

3. Provide a different box for the restricted users to log into.

What firewall configuration did you have in mind that would let you do this?

--
Jefferson Ogata : Internetworker, Antibozo


2. How do I add default route for PPP interface as non-root user?

3. restricting user access to an ethernet interface

4. TCSH for Solaris 2.4, where?

5. Restricting access from network for different users.

6. POP setup

7. Can I restrict access to an interface by _user_?

8. Function of Wheel Group

9. Restricting use of a network interface

10. Restricting network interfaces to superuser and/or specific gids/uids?

11. SAMBA - Restrict to one interface(network)

12. restricted shell or restricted access

13. Restricting user access to directories