gabriel rosenkoetter on 7 Dec 2003 09:43:02 -0500


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

Re: [PLUG] network security thoughts/questions


On Fri, Dec 05, 2003 at 04:43:15PM -0500, Jeff Abrahamson wrote:
> 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.

pros
- configuration is centralized
- configuration is relatively simple and well documented

cons
- your DNS will break all over the place and you'll have to figure
out how to make split DNS setups work if you want both the systems
inside the network to address each other by name and systems outside
the network to address systems inside the network by name
- gateway host is a bottleneck (but probably not a big one)
- without real NAT, you've SERIOUSLY interrupted access to systems
inside the network

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

pros
- once it's in, this is very clean: you can silently filter packets
without interrupting IP addressing
- good learning experience
- configuration is centralized

cons
- good learning experience (this ain't easy)
- configuration is VERY HARD (you'll need to figure out how to proxy
arp properly for all those internal hosts AND the CS department will
have to honor your proxy arping, which many poorly-behaved switches
and routers--which are stepping above their OSI caste in so doing--
won't)
- configuration isn't documented anywhere specific to Linux that
I've seen (most people who do this sort of thing do it with a real
piece of networking hardware, like a Cisco 6500 series router)
- gateway host is very definitely a noticeable bottleneck (without
some kernel modifications, you'll probably be running into
situations where the arp table fills up on the gateway host and new
connections simply stop working on a daily basis; it's not difficult
to deal with this situation, but the generic Linux kernel isn't set
up for it and I don't even know what to tell you to change for Linux)

> Scenario 3 (harden only): leave them as they are now, just harden the
> iptables rules on them to make sure they make sense.

pros
- you already know how to do this
- you may, in fact, already HAVE DONE this

cons
- configuration is completely distributed and may be different on
each host; maintenance will be a royal pain (and don't imagine that
this will be set-and-forget; consider that when there's an IP Tables
security vulnerability you will HAVE to update the relevant bits on
ALL of the systems)
- not much of a learning experience

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

I don't understand why. You appear to be stuck in the Linux-centric
concept of "IP Masquerading" (which isn't, in fact, what network
admins call masquerading, but whatever). Do full (source AND
destination) network address translation and there should be no
difficulty addressing internal machines by their formerly-used,
globally-routable IP address from outside the network. You'll
probably need to add all those globally-routable addresses as
virtual interfaces on the gateway's external interface.

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

This point is moot if you do real NAT and configure split DNS (use
BIND 9's views). If you're lazy about the second half, don't use DNS
for hosts inside to speak to other hosts inside; simply maintain an
/etc/hosts (rsync + ssh with a null-passphrased SSH key as root from
a locked down and NOT globally-accessible host is your friend).

Option 1 is by far the most oft-traveled path. You'll find plenty of
documentation on how to do this right. I can give some networking-
level descriptions, but I've never used IP Tables except for per-host
firewalls, so I can't help with that much (now, if you were doing
this with ipfilter on NetBSD or Solaris...). I can probably help
with questions about BIND 9 and split DNS, but I'm a bit hazy and
hand-wavy myself about that at the moment.

-- 
gabriel rosenkoetter
gr@eclipsed.net

Attachment: pgp8PV2MvU7v6.pgp
Description: PGP signature