[aklug] Re: Remote access to data

Go straight into the lan, 1 shot, JUST ONLY USE KEYS and a HIGH misc port.

If this was to get exploited by a 0 day then it's not a faceless program
running, it's someone patiently directly targeting you, which
is unlikely - I would think. All the ssh/ftp garbage we see in our logs
comes from auto rooters focused on standard ports with standard login
methods - username:password.

If complex security is what your after, then use a vpn (aes/sha1 - certs...)
into the dmz, then ssh through a pinhole into your lan. This way the same
0day isn't going to be used to exploit the pinhole as was used on the dmz.
Mixing the access methods disrupts the kill chain.

If the above way was to be used then it's not a bad idea to use a cronjob on
the dmz machine to remove your known_hosts file. No need to tell the baddie
where to go...Worry not if ssh is the most current - doesn't print ip in
known_hosts file.

--eddie

-----Original Message-----
From: aklug-bounce@aklug.org [mailto:aklug-bounce@aklug.org] On Behalf Of
Damien Hull
Sent: Thursday, December 06, 2007 1:33 PM
To: Arthur Corliss
Cc: aklug
Subject: [aklug] Re: Remote access to data

Arthur Corliss wrote:
> On Thu, 6 Dec 2007, Damien Hull wrote:
>
>
>> I'm at the coffee shop trying to access my data back at the home office.
>> I have access to my DMZ. Most of the time that's all I need access to.
>> Today is a little different. I'm missing a few files on my test server.
>> I need to access my data storage server in the internal network.
>>
>> I could do one of the following.
>>
>> * Allow ssh into the privet network
>> o green interface on IPCop
>> * Setup a VPN
>> o Doesn't give me ssh access
>> o I would only be able to grab data on the shared directory
>>
>> I'm sure there are other options. I'm looking for suggestions. Any ideas?
>>
>> Oh, I'll be leaving town next week. I would like to have something
>> configured before then. I will need access while I'm away.
>>
>
> Allow ssh into the DMZ to a bastion host, then allow ssh from only
> that bastion host from the DMZ into your private network. The VPN
> idea isn't bad as well, depending on how you implement it, but ssh'ing
> reduces the size of the aperture into the network. If you're running
> your own CA with client authentication via certs that might not be that
big a deal, though.
>
> In general, you should never let any given connection traverse
> multiple security zones in one fell swoop.
>
> --Arthur Corliss
> Live Free or Die
> ---------
> To unsubscribe, send email to <aklug-request@aklug.org> with
> 'unsubscribe' in the message body.
>
>
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 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.

Any suggestions?

NOTE:
I only have access to my DMZ for safety. Anything I deploy for internal
network access needs to secure and stable. The rest is extra at this point.
---------
To unsubscribe, send email to <aklug-request@aklug.org> with 'unsubscribe'
in the message body.

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Thu Dec 6 14:04:44 2007