[Courses] [Security] Port forwarding with SSH and ipchains/iptables

[Raven, corporate courtesan]

Heya --

Quoth jennyw (Wed, Mar 20, 2002 at 11:20:56AM -0800):
> Yes, the workstations cannot have ssh installed on them. They're Windows
> boxes. I guess it's possible to install SSH on them, but non-commercial
> implementations seem to be in some pre-release stage right now.

	I think the masses have answered this one.  [grin]
 
> Why I was asking about SSH instead of VPN ... well, the fewer features
> offered the better. I realize that a lot of VPNs have ACLs that you can set,
> but I'd feel safer if the product being used to secure the connections
> didn't have the ability to offer full-blown access to a computer or network.
> I could be paranoid here, of course.

	Paranoia is a virtue in security.  You're constantly thinking,
"What if this happened?  What if we lost that?"  Actually, I don't think
it's just security -- the same sort of thought pattern has served me
well in network design, too.  Single points of failure are bad,
basically.

	As for the VPNs, ones that offer ACL (access list) or
firewalling capability are good, but also keep in mind that in order to
speak VPN, there has to be a compatible VPN-decrypter on the other end.
So while VPN products will make your computer treat things on the remote
side of the network just as they would be treated if they were on the
same physical network, it's only (with a decent VPN) the other computers
on your network that will see this.

	Poor implementations of cryptography can be broken, and the rest
of the world might be able to see your VPN traffic as it transits the
Internet.  This is why it's important to choose a good VPN product.
It's almost exactly like wanting to choose a good SSH implementation --
SSH version 1 (ssh1) has problems of this sort.  Using ssh2 is more
secure.

	Also, keep in mind that all this VPN stuff is traveling over IP,
and you can firewall on that IP packet just as you like.  Most of it
travels over TCP within IP, and that's firewall-able, too.  But if you
want to firewall between the machines on your LAN and you're using a
VPN, then you will want a VPN that supports ACLs.

	Another thing you can do -- run your VPN on the firewalls.  Once
the traffic gets decrypted, it can be firewalled like any other traffic.
So even with a VPN, you can firewall within your LAN.

> Then agian, I've started looking at SSH port-forwarding, and I saw an
> article that suggested that having multiple computers access an SSH
> forwarded port might not be the best idea. So maybe we'll go to using
> a VPN after all ... it'll probably take some testing.

	That's what I'd do.  Testing before deployment is definitely
your friend.  And there are free Unix implementations of VPN, too, so
you don't have to give up on Open Source if you do decide to go the VPN
route.

> My assumption is that the way to do this would be to install FreeS/WAN
> on the firewall.  The rules on the external interface would be set to
> allow IPSEC. FreeS/WAN would then decrypt packets and then send them
> to the external interface.

	Internal interface on that last, but other than that, yes,
exactly.

> The external interface would have rules such that it would only
> forward packets that originate from e.f.g.h (the ext. interface of the
> client firewall).  Furthermore, it would only forward packets to
> Server A. Further still, only packets that come through on port 80.

	If it's using IPSEC, that changes the packet format and port.
If you mean "original non-IPSEC destination port was 80", then yes.  If
you expect the IPSEC packet to look like that, no.  

> Hasn't been implemented yet. We're currently using the port-filtering
> firewall capabilities of our routers (blocking all incoming traffic plus
> NAT). If we setup the Linux firewalls, it'd probably 2.4. Even if everything
> works technically, ease of maintenance will be an issue, since I may not
> always be available.

	I'd recommend 2.4 over 2.2.  It gives you far greates control
over firewalling, it's not significantly harder (the syntax is very
similar, just another few options to learn), and it's mature enough and
tested enough now that you can use it on a production system without
worrying too much.
 
> I guess another side of security is how easy it is to maintain, especially
> if you have staff turnover.

	Yes.  The most secure setup in the world won't save you if the
admins don't know how to maintain it.  I would highly recommend writing
up docs explaining your setup, what the various config files ought to
look like, and how to troubleshoot if there's a problem.  Personally
train at least one other person besides yourself.  That way you're not a
single point of failure.  [grin]  If I get hit by a bus, I like to know
my systems will be okay.  (And I get called less often at 4 AM if
there's someone to share the load.)

	And it goes without saying, but... keep those docs in a safe
place.  Imagine the glee that a black hat would have, finding a full
how-to on your network.  If you store them online, make that on a secure
internal server that a) doesn't run IIS and b) requires a login or
certificates, or something similar.  Firewall that box to the admin's
machines only (another good reason for static IPs on those admin
workstations).  If you store them offline, make sure they're not
accessible to just anyone walking by.

> This aspect might make us do something like buy a packaged product.
> For example, Smoothwall is based on Linux (2.2.19) and includes
> FreeS/WAN. Might not be the best, but it might be easier (I believe
> they allow you to manage it via a Web browser). If not that, then
> maybe SonicWall. I'd love to use Linux to help secure our network, but
> if it's not the best choice, then we'll go with something else. And
> anything I learn about Linux security can be applied to another
> project ...
 
	I haven't used any of those commercial products.  Has anyone
else?  Your managers might be happier with something like that -- if
there's tech support and accountability, that makes management happy.  I
tend to be contrary, roll my own solutions, and then document and train
our staff on that.  But your needs may differ. 

	In general, I've been far happier with *nix solutions than
otherwise for security.  While many Linux implementations are poor at
security out of the box, I know how to lock them down.  When I was also
adminning Microsoft boxes, I repeatedly came across "there's no way to
do that yet, wait for the patch".  Argh.  

	If you do decide to go with a commercial product, tech out your
sales engineer ahead of time so that you know exactly what you're
getting into.  And make sure how much monkeying you're allowed to do
with the system before you void your support contract.  (I run into that
one fairly often with Sun.  The only way to fix X is to install this
third-party patch, but that voids your contract...)

Cheers,
Raven

"And then we release the killer bees, with dogs in their mouths!"
  -- ChrisJ, on "get away from my router" tactics