Ruse, Kevin KPSI on 8 Dec 2003 17:11:02 -0500


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

RE: [PLUG] network security thoughts/questions


Title: RE: [PLUG] network security thoughts/questions

 

> -----Original Message-----
> From: Jeff Abrahamson [mailto:jeff@purple.com]
> Sent: Friday, December 05, 2003 4:43 PM
> To: PLUG
> Subject: [PLUG] network security thoughts/questions
>
> One of my Winter break projects is to improve security in my
> lab.  I'm interested in your experienced thoughts lest I
> overlook something obvious.
>
> What I have now is a half dozen linux boxes (and a Windows
> box whose fate is unimportant to me).  I have IP addresses
> for all of them.
> They are on the same subnet with the rest of the CS department.
>
> Scenario 1 (private LAN): make one box the gateway, put two
> ethernet interfaces on it, and put all other boxes on a
> private network
> (192.168.0.0) behind the gateway.
>
> Scenario 2 (public LAN): make on box a gateway, put two
> ethernet interfaces on it, and put all other boxes behind it,
> but still with their existing ip addresses.
>
> Scenario 3 (harden only): leave them as they are now, just
> harden the iptables rules on them to make sure they make sense.
>
> The only services we run that are needed from the outside are
> a lab web server, sshd, and sfs_server (an authenticated,
> encrypted NFS that I have not yet set up, but plan to as part
> of this project).
>
> In option 1, I'd either run sshd and sfs_server on the
> gateway or open tunnels for them to some inside machine.  In
> options 2 and 3, I would run whatever services I need to on
> each machine.
>
>
> I will admit up front that I don't understand the pros and
> cons of scenario 2 very well.
>
> Comparing 1 and 3, the private LAN of 1 seems simpler and
> more secure, but may be more intrusive to operations and
> people's workflow.  In addition, I wonder how long it will be
> before there's some problem with key authentication, either
> with SFS (in which host names and public keys must match) or
> with ssh (to scp past the gateway in one step, I would
> typically first ssh over it with "ssh
> -L8022:inside-machine:22 gw" and then "scp -P 8022 foo localhost:foo"
> to copy foo to inside-machine.)
>
> Three seems like it could be made almost as secure as 1,
> except that if someone opens an insecure port on a
> workstation, it will be seen in the outside world.  Also,
> there's more to pay attention to.  On the other hand, there's
> a lot of simplicity in running services.
>
> An additional advantage of the private LAN solution of (1) is
> that a compromise of the gateway doesn't risk internal data.
>
>
> Any advice?
>
> --
>  Jeff
>
>  Jeff Abrahamson  <http://www.purple.com/jeff/>  GPG
> fingerprint: 1A1A BA95 D082 A558 A276  63C6 16BF 8C4C 0D1D AE4B
>

You should harden all the machines regardless if you make your own internal network. You could probably get away with just limiting the services available and using host.allow and deny files. Adding a firewall would be nice assuming the wiring could be kept down to a minimal fuss. The more layers to the onion the better. 

You could also assign all your current ip addresses to the external interface of the firewall machine and then port forward them to your internal machines, which should make the firewall machine relatively transparent to the outside.

Kevin Ruse
Kvaerner Philadelphia Shipyard