WAN (Restriciting Remote Access)

[Joey_Batch_File]

Picture this: You have a WAN using NIS for authentication. You plan to add another remote site to the encryption device (NES). However, the plan is to keep the new remote site from accessing the remote nodes on the WAN. How can you configure the server to enforce this separation of remote sites? There are no UserIDs for the Server on the new remote PC, but there is Users on the server having UserIDs on the new remote PC.

[Joey_Batch_File]

We came up with a possibility of using two NIC's, but I was told the SUN system would automatically start working as a router. Our original diagram is attached.

we recieved this responce:

I start to get a little nervous with the introduction of a
second NIC to the server. I know in the Sun world, as soon as the
OS sees a second card, it assumes the server should act as a router
and begins acting as one. Let's talk about another approach...

Anytime you add a new NES into an existing configuration, you must
update all NES configs to see the new connection and addresses that
go with it. I think you could simply define the non-******* NES config
saying that this NES can only talk to the server, and that's it.
That would stop them from being able to look down the link at any
thing else on the network. As they sit at their terminal attached
to their NES, that NES would simply not allow any traffic to flow
through it unless it was destined for the desired server. There
are two sides to the config, in other words, both NES configs would
limit who could talk over that connection.

Now once you know the users can only connect to the one server, how
do you limit them to just putting files there? I think normal
permissions restricting the directory structure should be enough
to do what you want. I was a little unsure of how you wanted to
restrict the users once on the server.

Just realize there are groups and relationships defined in the
NES config that should restrict IP traffic as needed across the link.

We are going with the permissions, but is there any other ways to secure it more?

[nebulus200]

Uhhhh...if memory serves, for suns, just :

touch /etc/notrouter

No more routing....

Look at /etc/rc2.d/S69inet (to find this I did a grep 'route' /etc/rc2.d/*)

Below is the relevant snippet:

if [ -z "$defrouters" ]; then
#
# Determine how many active interfaces there are and how many pt-pt
# interfaces. Act as an IPv4 router if there are more than 2 interfaces
# (including the loopback interface) or one or more point-point
# interface. Also act as an IPv4 router if /etc/gateways exists.
#
# Do NOT act as an IPv4 router if /etc/notrouter exists.
# Do NOT act as an IPv4 router if DHCP was used to configure
# interface(s)
#
inetifaddrs="`/usr/sbin/ifconfig -a4u | /usr/bin/grep inet`"
numifs=`echo "$inetifaddrs" | /usr/bin/wc -l`
numptptifs=`echo "$inetifaddrs" | /usr/bin/egrep -c -e '-->'`

if [ "$_INIT_NET_STRATEGY" = "dhcp" ]; then
numdhcp=`/usr/sbin/ifconfig -a4 | /usr/bin/grep -c DHCP`
else
numdhcp=0
fi

if [ ! -f /etc/notrouter -a $numdhcp -eq 0 -a \
\( $numifs -gt 2 -o $numptptifs -gt 0 -o -f /etc/gateways \) ]; then
#
# Machine is an IPv4 router: turn on ip_forwarding, run
# in.routed, and advertise ourselves as a router using router
# discovery.
#
echo 'Machine is an IPv4 router.'
/usr/sbin/ndd -set /dev/ip ip_forwarding 1

[ -f /usr/sbin/in.routed ] && /usr/sbin/in.routed -s
[ -f /usr/sbin/in.rdisc ] && /usr/sbin/in.rdisc -r

else
#
# Machine is an IPv4 host: if router discovery finds a router
# then we rely on router discovery. If there are no routers
# advertising themselves through router discovery
# run in.routed in quiet mode. In both cases, turn off
# ip_forwarding.
#
/usr/sbin/ndd -set /dev/ip ip_forwarding 0

if [ -f /usr/sbin/in.rdisc ] && /usr/sbin/in.rdisc -s; then
echo 'Starting IPv4 router discovery.'
elif [ -f /usr/sbin/in.routed ]; then
/usr/sbin/in.routed -q
echo 'Starting IPv4 routing daemon.'
fi
fi
else
/usr/sbin/ndd -set /dev/ip ip_forwarding 0
fi

Even if there were no comments that specifically tell you this, you could still see the code:
if [ ! -f /etc/notrouter -a $numdhcp -eq 0 -a \

The first statement is saying, if the file /etc/notrouter doesn't exist (-f tests existance of a file, ! means not and -a is and -eq is equal (man test)...

Regardless, you can see that if the file is not there, it will started routed, if is there, it skips down to the else and turns off ip forwarding...



And this is just my humble opinion, I don't think I would be using NIS for authentication (and our policy pretty much prevents us from doing that, but that is neither here nor there)...way to easy to misconfigure and therefore for others to abuse...

Nebulus

[Joey_Batch_File]

I will run that across, but I have a feeling they want to avoid the two nics. I will let you know the update. Thanx again!