[aklug] Re: Remote access to data

- FLAME SUIT ON

>>"a) it assumes you're always going to be on your host"
>>"b) if your laptop is stolen someone now has passwordless access to your
host."

True - The key is needed, it can be stored on a usb key with putty. Or
requires your laptop. Heck, since we have come to the topic of laptop theft
and usbkeys, one word - gnupg. Use it to encrypt the key then if we're that
worried... Debian also has a nice little option to encrypt the filesystem on
install. If the threat is that great or the environment that sensitive and
we're that reckless then use gnupg and filesystem encryption inside the noc
and out...Crux delt with.

>>"Unless, of course, you're encrypting the key, in which case what's the
difference between typing a password/passphrase locally versus remotely?"

Password protect the the private key, which is never sent over the wire.
That's the difference to the remote password, that and a prompt on the
remote system for the *exploit*. I'm not saying ya need a prompt for a BOF,
I'm saying it's less of a issue without one. I like PKI ;) Solves the whole
transport issue.

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

I know the threats very well. Port knocking is still overkill outside of
high risk environments and is nothing new, sadoor has been around a lonnng
time. It's not so much security through obscurity as it is inconvenience
through simple trickery or KISS. The security through obscurity debate is
/dev/null these days; happened after authentication/authorization came
about... ;)

>>"Finally, if you have a DMZ, you should use it."

I fully agree.

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

I will say again, you don't want to give the baddie a chance to input data,
hence the key method - no login prompt, no dictionary attack, less vectors.
Honestly not using dsa keys is just *silly* in today's environment. DMZ or
not, if I exploit a service on any segment I'm gonna look into doing it
again to gain another host or segment. I mix access methods, so not only 1
exploit is required to bring the castle down. I think you have misunderstood
me, I believe in DMZs greatly, when designed effectively. BTW, when was the
last shell shoving exploit for the sshd key exchange? I know of one, lonnnng
ago.

>>"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 your interested in some of the tools that are used in these
SQL/SSH/FTP/RDP/Mail scans and current botnets please contact me off list,
I've caught/tracked a crap load in my honeynet. Keep in mind, we're talking
about sshd. No script kiddie is gonna modify his little tool to search the
internet for port 30761 for ssh, when he can have hundreds at port 22 with
username and password login prompts. I feel we're amiss to the real threats
and risks here.

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

Yawn, IPSEC on a border device...

Let me add here this to, if your going into the dmz, don't store the priv
key for the next hop into the lan on the dmz machine, transport it after
connecting to the dmz host.

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

Little exercise, find more than known_hosts and history files, all of which
can be cleansed - client side only...When due diligence has been followed
not to connect from a lan host, see below.

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

Lol, tcpdump -i eth0 port 22 under a screen process, not to complicated
really. The "real" blackhats stay native as possible. Depend upon weak
passwords and poor system monitoring.

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

I fully agree, connections made to a server leave lot's of tracks. BUT, not
only do I believe in rock solid boxen, I also believe in rock solid
networking devices to. Just make all your connections from the wan, gw
natting the protected networks. This removes all evidence of the connection
being sourced from the lan. If you do things right, no pinhole is even
needed when gw natting is used; would this be "security through obscurity"?
- I tease :)

I believe in DMZs, I build them and use them, dare I say humbly for some big
companies. If your after high security in a dmz then follow some simple
tangents.

1) ssh keys only, pass protected with a nice long complicated password - no
root logins! If your really worried of someone getting your key - gnupg.
Ssh v2 only!
2) lan priv key isn't stored on dmz host
3) mix access methods and devices
4) don't use default ports; this likens the baddie to make more noise if he
actually gets that far to do so.
5) if you can, use acls on border devices as to who can src
6) nat protect networks through you border device, to look as if connections
came from the wan when infact they came from the lan when accessing the dmz
and also from dmz to lan - no pinholes ever.
7) follow common sense server hardening
8) log as much as you can keep up with, be strategic and think as if it has
already been whacked
9) devices that leave the noc are encrypted - period
10) relax, learn your threats and risks

So I'm gonna drop from here, I know better than to tangle with ya to much
Arthur. Do know though, feel free to contact me off list about the above,
would love to show ya some things, seeing as to your playing with forensics
lately; albeit M$, cough cough.

Peace out,

--eddie--

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