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

[Raven, corporate courtesan]

Heya --

Quoth jennyw (Mon, Mar 18, 2002 at 02:59:42PM -0800):
> Sometimes I learn better by doing. I have this project that might be
> possible to do with SSH and iptables/ipchains, but I'm not sure. Since we're
> kind of on the subject, I thought I'd ask (feel free to tell me this is off
> topic).

	Not at all -- this is very relevant to our security discussions.
This should make for some interesting plotting.  [grin]
 
> Here's the situation: There are two networks, A and B. Each network has its
> own firewall. A client behind Firewall B wants to talk to a Web server
> behind Firewall A.  Unfortunately, the service it's connecting to on network
> A is an insecure Web app. Moreover, the only exposed IP addresses are the
> external interfaces on the firewalls. Additionally, neither Server A nor
> Client B can run SSH -- SSH can only run on the firewalls.

	Out of curiosity, why is this?  (I'm assuming that you mean here
that the workstations cannot act as ssh servers.  Or do you also mean
that they can't even have ssh clients installed on them?)
 
Server A (Web server)
     |
 10.0.0.1
Firewall A
 a.b.c.d
     |
<The Internet>
     |
 e.f.g.h
Firewall B
 10.1.0.1
     |
Client B (Web client)

	Heh.  ASCII art.  I was never fond of it before I started doing
networking, but it's so helpful to explain in situations like this.
 
> Would it be possible to set things up so that if Client B connected to
> a.b.c.d:80 it would have a secure connection to Server A?
 
	Yes.  The question is, what's the best way to do it?

	The "traditional" answer in this case would be a VPN.  Sending
sensitive data over untrusted networks is what VPNs are for.  That's
their entire purpose in life.  There are a lot of different options for
VPN products out there.  Before you and your company spring for one,
investigate what you're buying in detail.  The advertising for the VPNs
that work and the ones that are poorly implemented sounds exactly the
same, and it's hard to tell what sorts of VPNs are good without being an
expert.  In general, I would distrust anything that used proprietary
cryptographic algorithms.  Peer review by the cryptography community is
essential -- the more eyes looking at your algorithm, the better chance
that they'll find any errors.  The most trusted algorithms today (public
ones, anyway) are ones that have withstood peer review, and aren't easy
to force.

	Without being a cryptographer, how do you know?  Search Bugtraq
archives and see if the product has a history of problems.  (Product
names and algorithm names are good things to search on.)  Google for it,
and read reviews from others using the same product.  If you belong to
SAGE or a LUG, ask around and see if others of your peers have had
success or problems with a given product.

	 There are several ways that VPNs can be implemented -- in
short, you can do them at every client, or you can do them on the router
or firewall.  Assess the needs of your company, and see which would be
easier to set up.  You might want to check out the O'Reilly book on
Virtual Private Networks, too.  I read it before my first VPN
deployment, and it was a lot of help.

	Now, if you don't want to VPN it for some reason, you have other
options.  You can have your firewall B intercept all packets for the web
server and use SSH-forwarding to send them to a different port on
firewall A.  Then, firewall A terminates the SSH session, and uses port
forwarding to send the packets to the correct destination server.

	This will be middling-complex to set up.  If you want to do this
for several services, for several servers, you might be better off with
the VPN.  But it's doable with ssh and port forwarding (part of the
whole firewalling package).

	Note that with this solution, the packets are only encrypted as
they cross the Internet.  The path between your client and firewall B,
and between firewall A and the server, will still be cleartext.  So it's
possible that other devices on your LANs could intercept this traffic.
This may be an acceptable risk, but you should be aware of it.  If you
go with a VPN product that's implemented at the firewall or router,
you'll have this same problem (most likely).  If you go with a VPN
product that's on every client, this may go away.

	(If you ran SSH servers on the client machines, even locally, we
could do port forwarding off those to the firewall, and just do
redirection at the second firewall, producing end-to-end secured
communications.  But since you can't have SSH servers on the client
machines, this isn't an option.)
 
> P.S. Why do I want to do this? Weirdly enough, it's to secure a security
> application. Silly, but true.

	Argh.  But it's good that you realize that this needs doing.

> To secure all sites against virus attacks, we're looking at Trend VCS,
> which is a master control app. (or program, for Tron fans) that
> connects to sub-servers at other sites.

	You may also want to look at filtering known viruses off your
mail servers.  There are lots of applications out there that will do
that for you, and are compatible with various sorts of Unix mail
servers.  I believe this is possible for Exchange servers too, but I
don't know a lot about how to do that.  (Not a Microsoft admin.)
	
> Unfortunately, it does this over HTTP. Even more unfortunately, it
> does this using IIS (they'll change this soon). Worse yet, everything
> is plain text (actually, Trend says that server to server
> communication is secured by some proprietary method that they have no
> details on, but I have serious doubts).

	Uh-huh.  I wouldn't buy it (the story or the app).  Fire up
tcpdump (I must get that tutorial out) on one of these sessions and see
what you can get.  I'll bet you can see every last bit of the traffic.

> Inside a LAN, it's not as big a deal, but over the Internet, it's not such a
> hot idea. So people use VPNs for this. Which is great, except that I'd like
> a simpler solution, and I suspect that SSH can do this. Not sure, though.
 
	Ssh port forwarding is relatively easy, and the firewall part of
port forwarding isn't too bad, either.  But the VPN may actually be a
simpler alternative, depending on your site's needs. 

	What kernel series are your firewalls running?  2.2 or 2.4?

Cheers,
Raven
 
"Sed, sed, awk.  Like duck, duck, goose.  Sync, sync, halt.  It's the
 order of nature."
  -- me, after too long a day at work