[aklug] Re: Remote access to data

From: Arthur Corliss <acorliss@nevaeh-linux.org>
Date: Thu Dec 06 2007 - 14:52:19 AKST

On Thu, 6 Dec 2007, Damien Hull wrote:

> I think I'll go with the ssh option for now. It's easy to configure and
> allows command line access to hosts on the internal network. I guess I
> could add another bastion host. One inside the privet network.
>
> The hacker would have to log into 3 systems. The bastion host on the
> DMZ. The bastion host on the Privet network. Then the host they want to
> hack into. Unless they are trying to hack something on the DMZ.

The extra internal bastion host isn't a bad idea, but really doesn't buy you
that much more security. As long as your firewall on the DMZ allows *only*
port 22/tcp traffic internally, it should be sufficient, and that's one less
box to administer. Of course, certain hosts internally (like your firewall
box or authentication server) should never be accessible from the DMZ.

> The only down side to this configuration is that downloading data
> becomes difficult. How do I grab data with sftp?
>
> * ssh into the first bastion
> * ssh into the second bastion on the privet network
> * sftp to the data storage server
> o running Ubuntu Dapper
> * grab the data
> * Work my way back to the first bastion host
>
> It's a lot of little steps. If I remember correctly there is a file
> system ssh thing. I used it once. Maybe there's a way to deploy that. I
> think it was called opensshfs or something like that.

More than one way to skin that cat. Leif's example can actually be used to
tunnel through multiple hosts (just add additional ssh's for each hop
forwarding the local port to the same port on the next host, etc). Or, just
tunnel in, tarball what you want, and scp straight out to your client or, if
your client is behind another firewall, just scp the file to your DMZ server
where you can grab it directly. Any way you cut it, it can be as little as
just one extra step.

         --Arthur Corliss
           Live Free or Die
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Thu Dec 6 14:52:33 2007

This archive was generated by hypermail 2.1.8 : Thu Dec 06 2007 - 14:52:33 AKST