On Fri, Dec 18, 2009 at 10:59:14AM +0000, Wayne Stallwood wrote:
Chris G wrote:
Normally the intruder would be coming from a different machine and wouldn't have the private key in the first place.
Not generally true unless they're doing IP spoofing as well because I only allow access from two specific IP addresses.
No...no..no..no
Connection from specific addresses is not to be considered a primary layer of security, it is a secondary one.
Yes, I realise that, it's easy enough for someone to spoof the IP addresses I'm allowing. It will prevent most scanning though.
Your initial layers (from the something you have/are/know model) should be good enough that you would be happy enough using just one. Quite obviously an ipaddress isn't sufficient for that. So you need to build a secure layer of authentication first and then layer on top things like blocking from all but specific addresses as belt and braces.
Quite agree.
Put it another way, I am guessing you are on a NAT'ed connection at home yes, so blocking access to an external machine from your external ip address doesn't just restrict access to your machine. Anything on your local network has this capability, as does anyone wanting to try at various points down the line, including your ISP or the ISP that is hosting the other machine.
I'm not quite sure I follow you here. Yes, our little (three or four machines) SoHo network is NAT'ed by a Draytek Vigor 2820n router. It's the router that only allows specific IP addresses to connect. The local network is 'trusted' in that it's just family (OK, they're not perfect but they're not malicious attackers either). Thus I'm not worried about people hacking into my [desktop] machine from other machines on the network behind the router.
Yes, other people with a shell login on the machine 'out there' will have the same (permitted) IP address. I'd already said that and agreed that it is something to be considered. However it's not a machine with hundreds of users, shell logins there belong to paid for accounts, they're not freely available. I.e. it's certainly not a trusted machine but it's not at the other extreme either.
You are making the same fatal assumption people do when they stick a firewall in front on an inherently insecure network and figure that makes them safe. The reality is you are better building a network that considers everything as equally untrusted until it has authenticated itself properly. That way if the firewall is breached or the attack comes from the private side of your network you are still going to give people a hard time....Good networks shouldn't *need* the firewall to be secure. By this stance you can treat blocking from all but specific IP addresses the same way, yes it helps but it is too easily spoofed so don't depend upon it.
As I said the private side of the network *is* secure and trusted. Anyone who can get to the private side can physically get at the computers anyway in which case everything we're talking about here is pointless.
The important case for me is access from 'out there' in to my machine (well, in to my server machine actually, there's a further hurdle to my desktop machine). The 'out there' machines are not mine, most definitely 'untrusted', the security rules then suggest that you *shouldn't* keep any private keys there.
No you don't do that, each machine 'out there' has it's own private key and put it's corresponding public key into authorized_hosts on your server. That way you can revoke access to an individual machine by deleting its key.
Well other advice I've read doesn't agree with this. It suggests that you use a 'remote keys' set up with ssh where the keys (the private keys for the untrusted client systems) are kept on trusted hosts.
If you are talking about machines "out there" to which you have had no prior access to set up the keys then I would suggest that a. if
No, I do have access to set up ssh keys there. The process when I'm out on the road as it were is:-
Connect my 'throw away' EEEPC to WiFi or whatever
Use ssh to connect to one of my 'out there' shell logins
Then ssh from that shell account to my home system.
you care about security you shouldn't be logging into your home system from them anyway and b. there are options to carry your (passphrase protected) private key on a memory stick and symlink it to ~/.ssh on the machine you want to access from. Or (personally I found that option annoying due to uid mapping issues) do what I do. I carry a qemu based VM (running DSL) that is bootable on Windows or Linux boxes from a memory stick which has it's own private key. It's passphrase protected anyway but if I lost the stick all I need to do is get it's public key out of my authorized_hosts.
However if we are following best practice here then private keys should never leave a machine, and you shouldn't be establishing a trusted connection from an untrusted host.
That last bit is a counsel of perfection isn't it? It would mean one could never connect from the internet into one's home machine.
Don't make the mistake of dreaming up one possible attack vector and basing all your security measures upon that assumption. The fact is that if you are only allowing key based authentication then an intruder needs to break into your machine first *and* crack the passphrase on the private key. At the point your local machine is compromised and had you been using a password login to the remote system they could have just installed a keylogger or a login spoof and captured a password for the remote system anyway.
The key logger can capture my passphrase too can't it? Then the intruder has access to every system where I'm using that key.
Yes, but this is no worse than what a keylogger would do if it captured your passwords for interactive login. I was merely using this as an example of how key based auth doesn't *lower* security which is what you seem to be suggesting.
I don't think I was suggesting it was worse, rather that it wasn't much (if at all) better and being more complicated means one is more likely to get things wrong and compromise security that way.
At the point the passphrase(which can be more complicated if you like because you only need to remember one) is compromised you would have to assume that any and every password you have used on that machine would be equally so..no ?
I think your comments about the passphrase apply equally to a password. If there's only one passphrase (you said "which can be more complicated if you like because you only need to remember one") then all the issues are the same as if you only have one password for all your logins, in which case you could have an equally long and secure password which you would only have to remember once.
So overall if you are using passphrase protected keys you have still increased overall security because the private key has to be stolen and compromised first. Making an attack from a machine other than yours pretty difficult and an attack from your machine as difficult as if they didn't have a password for interactive authentication (they still have to guess or capture the passphrase, which is the same effort as guessing or capturing a login password)
I can see what you're getting at and I half agree but I'm not sure that the game is worth the candle still.
Well the beauty is that it isn't really *that* much effort to set up and the benefits are well worth the effort in my opinion. Unless you only have a few passwords to remember or they are very simple/reused often you will generally have a hard time remembering them all. So ultimately you end up recording them all somewhere anyway :)
As I said the "only one passphrase" to secure all those logins is surely *just* as bad as using the same password for all those logins.
Anyway, thanks for all the comments and help, I am taking some/all of it on board and tuning (rebalancing maybe) my systems' security as a result.