I have a bunch of Linux machines that I wish to administer over the Internet. I currently use SSH keys, but have been advised to use 2-factor authentication. SSH Keys are something you know. Is an IP address something you have? (Yes, IP can be spoofed, but so can biometrics and so can atm cards).
Could I lock down SSH to only allow connections from my IP range and would that be considered 2-factor in conjunction with SSH keys?
I would think of an IP address as being "somewhere you are" rather than any of the traditional "something you know", "something you have" and "something you are" that are part of 3-factor authentication.
Although IP addresses are trivial to spoof, TCP connections are not and SSH is a protocol built on top of TCP. The IP address of a TCP connection is a reliable indicator of who you are directly connected to.
Let's say I limit SSH connections to just my office IP address, an attacker is going to have to do one of:
Point 3. allows the attacker to be anywhere in the world but it increases the difficulty of an attack.
Points 1. and 2. significantly reduce the number of people who can successfully use the other factors (such as your SSH key or password) if they manage to acquire them and hence I see it as being worthwhile.
The quality of the IP address is a big factor here. I used my office as the example above but if you have a dynamic IP address, do you trust the entire range your ISP owns? How does that affect how easy it is for an attacker to get one of those IP addresses? Does the trustworthiness of an IP address change when you know there are 10 machines hidden by NAT behind it? What if there are 2,000 machines and 100 wireless access points?
I would not consider an IP address to be a factor on its own.
If done properly, it could be a somewhat useful addition to your security protocol. However, I'd be very hesitant about using it to replace a pre-existing factor in your authentication, as IP addresses are not secret information (you give it away to every website you visit) and depending on how/where you grab the IP address from, could be trivial to spoof. But if you use the IP address from a TCP connection in conjunction with say a stored secure http-only cookie, you could add some security. Specifically you'd invalidate the cookie whenever the IP address changes (which may change for benign reasons such as your ISP reassigning your IP) as well as malicious reasons (attacker got hold of your cookie).
As Ladadadada said, IP addresses in TCP connections aren't easily spoofed anymore. TCP requires a handshaking procedure to get a random 32-bit sequence number from the server before you can exchange information. If you forge a completely phony random IP address when starting the handshaking procedure, then the packets won't be routed to your computer through the internet, so you can't complete the handshake. Unless, that is you control intermediate routers at the ISP or a computer on one of the same local networks that could capture the packets routed to elsewhere, in which case you could forge random IP addresses.
However, if you design a web app and record the IP address, you have to be careful. Say you have a web app with two web servers (e.g., one for dynamic content/one for static), behind a load balancer, or other proxy. You may see by trial and error that the client's IP address is only present in the HTTP header X-Forwarded-For. However, this field is easy to change. For example, telnet www.whatismyip.org 80 and type the following with/without X-Forwarded-For the line (remember to press enter twice after the last line to indicate the end of your HTTP request).
GET / HTTP/1.1
Host: www.whatismyip.org
X-Forwarded-For: 1.2.3.4
and you'll see that this web app thinks your IP address has changed to 1.2.3.4. So be sure to test thoroughly. Overall, I think doing this yourself is more work than its worth, especially as it may frustrate users whose IP addresses change quite frequently.
EDIT: I realized after writing this that while I answered the title question ('can IP address be a component of 2 factor auth?"), but not the specific part referring to ssh management. I'd say ssh passphrase protected key is essentially two-factor auth: something you have (the ssh key), and something you know (the passphrase's key).
Typically 2 factor authentication refers to something you "know" and something you "have". The "know" is a password and "have" is ssh keys. These could be used the way you're using them now or on some sort of smart card or dongle (which sshd then accesses using the GSSAPI; see man sshd_config).
I think the person who asked you to use 2-factor authentication wants you to use keys and passwords (if someone steals your key it doesn't matter as they don't know the password either).
An IP address isn't really something you "own" because, as you've said, it can be spoofed. Same with MAC addresses. However, you can lock down sshd access to certain IP addresses/ranges anyway as a means of making harassing the ssh server more difficult. For example, running sshd on the default port on the internet will lead to lots of people attempting to brute force passwords etc.; restricting to IP addresses should aid with this as it requires more persistence and configuration to spoof the IP. Put a line similar to the following in /etc/hosts.deny
sshd,sshdfwd-X11:ALL
and this in /etc/hosts.allow
sshd,sshdfwd-X11: 192.168.0.0/255.255.255.240
sshd,sshdfwd-X11: 127.0.0.1
(the IP address/subnet mask above defines a range of addresses; it is just an example).
Always double check when making these sort of alterations as you don't want to accidentally lock yourself out of your server. Always leave a session logged in while you're testing (as these changes only affect new logins).
Technically yes, but adding a second factor that's trivial to forge doesn't increase your security by very much.
Assuming that you've been advised to use 2-factor because some sort of risk assessment suggested you needed stronger authentication, then you should be looking at better controls.
(Do the IP whitelisting too, though - it's not very strong but it'll only take a minute or two to do, so why not?)
The key thing is to remember that "2-factor" isn't a magic phrase that makes you secure. You need to understand the risk and implement appropriately strong controls.
Are the semantics relevant here? That you "have been advised to use 2-factor authentication" suggests that someone is expecting this from you - so doesn't it make more sense to find out from the person with the expectation what would be deemed acceptable?
No. You should not rely upon the IP address to provide much security. If someone connects over an open wireless network (say, from their smartphone, or from their laptop in a public coffee shop), then it is trivial to mount a man-in-the-middle attack or spoof their IP address. For those users, the IP address is not adding any security.
Therefore, if you were advised that you should use 2-factor authentication, you should not treat the client's IP address as a second factor. For some of your users, this will be basically useless.
I would say that it is fine to filter SSH connections to only allow those from a limited IP address range. This might increase somewhat. However, don't count it as a second factor! If you need two-factor authentication, use two real factors. Don't try to "pull a fast one" with a fake second factor.
Let me tell you a little story about another industry segment which pulled a fast one with 2-factor authentication. Several years ago, US banking regulators passed a regulation requiring all US banks to use two-factor authentication for online banking. A plausible requirement, especially if you're concerned about phishing attacks to steal people's banking passwords. But then banks went and got "clever" (and I don't mean that in a good way) about how they implemented the requirement. They decided that your online banking password would be the first factor (fine so far) and a persistent cookie on your machine would be the second factor (well, plausible). But how did they get the persistent cookie on your machine? Well, if you don't have the cookie, they ask you your challenge question, and if you can provide the correct answer, they give you the cookie. So in the end their two factors are: (1) a password, and (2) another password (the answer to your challenge question). This defeats the purpose of two-factor authentication. For instance, a phisher can just ask for both passwords. And indeed, some studies have found that this form of two-password authentication is no more secure against phishing than one-password authentication. So don't be like the banks. Don't treat 2-factor authentication as something you can game, because then you will negate its security benefits.
In a sense, yes. But it's more a matter of semantics rather than security.
In a certain sense, an IP address could be considered "something you are" or "something you have"; that is, if access is restricted to only a limited set of IP addresses, then an attacker would have to "be" or "have" one of those IP addresses in order to perpetrate an attack -- how that would happen depends on the scenario and technology, but it certainly will dramatically decrease your attack surface.
The semantics comes as part of the argument as to whether this counts as a second factor, or whether it's just a really good additional piece of security. Technically you are not your IP address nor it it really yours; someone else can assume control of it depending on network structure. But the same goes for any other piece of authentication technology -- it's all up to the implementation.
The only time it really matters whether or not it counts as a second factor is in the context of some sort of process audit or larger framework, in which case qualifying factors should be listed. Otherwise, it's just nerds arguing.
I would say that requiring a password plus imposing an IP restriction is very reasonable security, as long as the appropriate policies are strictly followed. It's certainly better than just the password alone.
You shouldn't use IP address as an authentication factor. It's easy to spoof an IP address instead of cracking other means like biometric. A script kiddie can do it easily.
How can you deal with IP address changes unintentionally like using VPN? There are a lot of solutions for using SSH two factor authentication. You can just Google them.
IP would just be way too easy to spoof or even guess based on a subnet. Only so many options there. I wouldn't consider it useful. There are a lot of other 2-factor systems you can use that are simple and work. Look at LinOTP and OpenOTP.
Another option is to restrict access to only machines that use a smart card or have another form of 2-factor already enabled.
Some practical answer that you may, or may not believe.
I once worked for a company that made a minor site for MasterCard. Mind you, it was not anything very security related, no CC numbers, no transactions. A small contest with small prices. But this means the site had a log-on mechanism and some personal information (login, email, maybe even postal address). The MC procedures mandated some form of 2FA for the production servers' management and IP based filtering, limited to 1 IP address (gateway from the building) was considered enough. On the other hand the site was such a low-value one they haven't bothered to actually verify what we said, they've taken our word for it. But including the IP filter as 2FA was their idea, they've explicitly asked for it, we haven't really thought then to include is as part of 2FA.
