[aklug] Re: Remote access to data

From: Arthur Corliss <acorliss@nevaeh-linux.org>
Date: Thu Dec 06 2007 - 15:18:09 AKST

On Thu, 6 Dec 2007, ep wrote:

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

The only problem with this is that it requires you to have a host with the
private key, i.e., your laptop. I *strongly* dislike this for several
reasons: a) it assumes you're always going to be on your host, and b) if
your laptop is stolen someone now has passwordless access to your host.
Unless, of course, you're encrypting the key, in which case what's the
difference between typing a password/passphrase locally versus remotely?
The local file, in fact, gives someone a method to brute force your password
that you'll never log or see anywhere else.

I also don't believe in the effectiveness of security through obscurity,
which is what the high port # implies. If you're going to go that far you
might as well go all the way and do port knocking.

Finally, if you have a DMZ, you should use it. Allowing someone to gain
access to your more sensitive network via *one* exploit is a horrible idea.
If you use separate passwords for the DMZ versus your internal network that
gives another layer of protection against dictionary attacks, and still
prevents someone from scanning the rest of your network for better/easier
targets.

In short, you have to weigh:

   1) your level of paranoia
   2) how much real security is gained for the extra administrative/user
      overhead

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

Given the modern incarnation of the botnets, I'm not sure I agree with
this. It's getting trivial for them to load a new attack into the net and
start looking for targets. Also bare in mind that 0-day is really a
misleading and poorly used term by most people. A 0-day can very well be a
100-day exploit that's just not been found and reported by white hats. It's
a 0-day for us, but not for the baddies.

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

Ironically, this, too, depends on where the hole was. A vulnerability
against openssl, for instance, could be just as big a problem for openvpn as
it is for openssh. If you're using completely different mechanism then
there is some value to this.

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

The known_hosts file is an interesting issue. The irony is that if someone
has already gotten shell on the box there's a ton of bread crumbs left that
can be used to figure out where the next box is with ssh services. The real
black hats probably wouldn't even risk port scans, they'd just leave a
process that logs tcp connections via netstat and retrieve that later. Or,
they could just go through local syslogging, because odds are connections
have been made from the internal network as well as the external network.

All of this points towards the need to harden the box. Information can be
leaked in a hundred ways on the average box.

         --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 15:18:26 2007

This archive was generated by hypermail 2.1.8 : Thu Dec 06 2007 - 15:18:26 AKST