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

[jennyw]

From: "Raven, corporate courtesan" <raven at oneeyedcrow.net>
> 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.

Yeah, that's what I was thinking.

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

Do you know of any besides FreeS/WAN? Have you had experience with any of
them? I know there's OpenBSD VPN, which is a reference platform for IPSEC.
It sounds good, and OpenBSD has a good reputation, but I've never used it
before, so I'm a bit hesitant to switch over.

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

Oops. Yeah, that's what I meant ...

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

Yes ... because at this point, FreeS/WAN (or whatever) would have unpacked
the IPSEC packet, so by the time it hits the rules set for the internal
interface, we're no longer dealing with IPSEC. Right?

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

It's good to hear that it's stable! I guess the bit of uncertainty I've had
is that a lot of commercial vendors are still using 2.2. Of course, that
could just be because their modifications are so great that there's
significant lag time before they can get the changes ported to 2.4.

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

Perhaps many of the reasons I've gone with non-Linux solutions in the past
are addressed by iptables. Is there a good place to read about iptables?
There are lots of Web pages out there. One of the things I'm wondering ...
what is meant by stateful inspection in the case of iptables? I'm used to
the Checkpoint definition of stateful inspection, which means looking at the
packet in context of a session (faked in the case of UDP) and also analyzing
packets through to the application layer (meaning so that you can tell
whether something is being sent in http or telnet or whatever, regardless of
what port it's coming in on, and also make sure that packets are valid for
the protocol). Is this the same meaning that's used with iptables? I ask
because I read an article on netfilter/iptables that described stateful
inspection only as session based. Also, am I correct in understanding that
the firewall features in 2.4 are called netfilter and that iptables is just
an app. that you can use to configure those features? If so, then are there
other netfilter-based tools besides iptables? I get confused when I read
something like "gShield is an iptables firewall". I think they mean
netfilter?

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

If we go with a vendor, it'll likely be Sonic, and there really isn't tons
you can do to a SonicWall appliance that would void the warranty (short of
doing something that you *know* would void the warranty). I just learned
that they're integrating Websense into their products, which is another plus
for them. I don't think there's anything in free software that's comparable.
Dansguardian and Squidguard would be the Open Source alternative for Web
filtering (if you know of others, please let me know!), but I'm not sure
they quite match up.

Thanks!

Jen