Re: Policy based routing/restricting access __inside__ ones net..

From: horio shoichi (horio@pointer-software.com)
Date: 09/23/01


Date: Mon, 24 Sep 2001 03:43:53 +0900
From: horio shoichi <horio@pointer-software.com>
To: Stanley Hopcroft <Stanley.Hopcroft@IPAustralia.gov.au>

Stanley Hopcroft wrote:
>
> Dear Ladies and Gentlemen,
>
> I am writing to ask for advice about providing profile dependent access
> to subsets of ones internal network.
>
> The context is having third parties access the network for maintenance.
>
> Once they get logged in on the host they are hired to maintain, how can
> I prevent them accessing other hosts while allowing __some__ access to
> others they may need for problem resolution ? (given that both sets of
> hosts can be specified)
>
> Can a Kerberos realm enforce access profiles such as these (and then if
> they were forced to use only kerberised applications, grant them tickets
> for access to some hosts only) ?
>
If you mean by realm to split servers into possibly overlapping set of
realms each of which has separate set of principals (users and services)
and
users access servers through cross-realm authentication, I see no reason
it
doesn't work.

> Can ipfilter/ipfw provide ACLs depending on user ?
>
Ipfilter is so low level that it has no notion of user. It only
recognizes
protocol, ip and port. If a user (or users) could be bound to a specific
set of protocol, ip and port corresponding to an instance of service,
then access control might be possible. But I doubt doing this would
worth efforts.

> The access could include Solaris/FreeBSD/AIX servers as well as MS Win
> NT ...
>
> Thank you,
>
> Yours sincerely.
>
> --
> ------------------------------------------------------------------------
> Stanley Hopcroft IP Australia
> Network Specialist
> +61 2 6283 3189 +61 2 6281 1353 (FAX) Stanley.Hopcroft@IPAustralia.Gov.AU
> ------------------------------------------------------------------------
> The study of non-linear physics is like the study of non-elephant
> biology.
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-security" in the body of the message

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message