Man in the Middle Attack

[ooboontwo]

The more one looks the more break-in attempts one can spot. It's the nature of being on the net. But there are more things that can be done to mitigate the probes and attacks.

It is considered good practice to have PermitRootLogin no on your server to eliminate even the chance of someone getting in that way, if you haven't set that yet. Eventually, unless your situation is unusual, you can turn off password authentication and allow only keys. That stops password guessers completely.

I have now set PermitRootLogin to 'no.'

I will also work on setting up key-based authentication today.

Also, iptables can do rate limiting to lock out attempts coming in faster than x per second or y per minute. UFW has a primitive for that, which is "sudo ufw limit ssh" which defaults to 6 per 30 seconds per ip address.

I ran 'sudo ufw limit ssh' in the terminal and received a confirmation message. Is that all I need to do?

Also, fail2ban gets mentioned a lot but you might look at sshguard first. That scans the logs and then uses iptables to block persistent failed attempts. But as you notice, they rotate ip addresses and that makes the attack harder to block.

I also installed sshguard. Now that it is installed do I need to make special configurations or should the default config work OK for me?

Are any of the ip addresses coming from your same ISP? You can use whois to look up which ISP is responsible for a given ip, if any look close but you are not sure.

All the IP addresses are coming from China/Hong Kong, so none are with my ISP (AT&T).

Thanks for all your help. I will continue to Google and research the things you've talked about. I don't want to waste your time when there is so much information on the net, or using 'man sshguard' etc.

Blessings,
Cody

[ooboontwo]

Did you take note of what the random username you used was? Check your server's auth.log to see if any attempts were made to log in using that same username. Maybe try it again this time with a different username that you would recognize if you see it in your logs afterward.

I do remember the username I tried but I haven't seen it in the log, probably because I physically removed the computer from its usual location and brought it to my office. Still, I will keep an eye on the log and see if this fake username comes up ever again.

Attempts on the root account are common on servers that have their ssh service open to the internet. This is why Ubuntu in particular disables root logins by default. It won't stop the MITM attempts or the errors, but it will prevent the attacker from getting usable credentials. The way key authentication works in ssh is the private key stays on your client (machine running PuTTY) and your public key is on the server you're logging in to. The two keys are related in that anything encrypted with one can only be decrypted with the other, but it's nearly impossible given one of the two keys to extrapolate the other. So, even if a MITM occurs and you attempt to log in to an attacker's box, they won't get anything useful that they can log in with. And if they manage to get into your server, all they can get is your public key, which can't be used to gain any access to anything--only the private key will.

The only thing passed between the client and the server when logging on using keys is an encrypted token. Your client (PuTTY) encrypts this token with your private key and then sends it to the server, which then attempts to decrypt it using the public keys stored in the authorized_keys file. If it is able to, it lets you log in. This token is useless outside the transaction, and nothing of the private key gets sent over the wire.

Also, if you set up the key credentials on your PuTTY and server, and you connect to the MITM server, you can try logging in and see if it works. If it does, you're either on your server or they copied your public key from your server to the attack server. If you get to a shell, you can do some looking around. But chances are the MITM box won't recognize your key and it'll revert to a regular password login prompt (don't be fooled and enter your password if this happens!)

This sounds much better than the way I've been doing it (password authentication). I will work on setting this up today. Thank you!

[kpatz]

Now that you physically moved the server, what happens if you try to connect to the server's original IP (assuming the server is on a different IP now)? Or if you use the DNS name, if you didn't re-point it? It might still route you to the false server.

Also, at the server's original location, you said it's behind a router with the port forwarded, right? Are there any other machines at that location, also behind the router? Does the router have wireless, and is it properly secured? (i.e. WPA2 and a good passphrase?)

It's possible the MITM is being done at the router, especially if it wasn't properly secured.

Once you get the keys set up, I think you'll like it better. If your PuTTY machine is secure (i.e. at home with no one else that has access to it) you could even get away without using a passphrase, and then you can log in without having to enter a password or passphrase. If you do use a passphrase, you can use an SSH agent (such as Pageant for PuTTY) to cache your key, so you only have to enter the passphrase once, and then you can log into any/all boxes that have that key set up on it without entering it again, until you turn off Pageant or reboot your PC. You can use the same key to access multiple servers, or multiple user accounts on the same server. Or you could use separate keys, your choice. I prefer to have a separate key for each client machine, and put it on all the servers I log in to. That way I can use Pageant or ssh-agent to cache the key and I can log in to server after server without re-entering my passphrase every time. And if one of my client machines gets compromised (i.e. someone steals my laptop), I can just delete the laptop's public key from the server(s)' authorized_keys file and then it can no longer be used, but I can still log in using the keys on my other clients.

[Lars Noodén]

It's possible the MITM is being done at the router, especially if it wasn't properly secured.

That's what I considered at first but there is apparently no spoofing on the LAN itself. So if it is a router, it is one further out. It might be the ISP's.

[kpatz]

That's what I considered at first but there is apparently no spoofing on the LAN itself. So if it is a router, it is one further out. It might be the ISP's.

When on the LAN, you aren't going through the router at all, but are connecting directly to the server. When outside the LAN, you're going through the router. So it could still be the router. Are there other machines on the LAN connected to the router? Is there wireless on the router?

[Lars Noodén]

I ran 'sudo ufw limit ssh' in the terminal and received a confirmation message. Is that all I need to do?

I also installed sshguard. Now that it is installed do I need to make special configurations or should the default config work OK for me?

All the IP addresses are coming from China/Hong Kong, so none are with my ISP (AT&T).

You can double-check UFW with iptables-save and see what it has set for ssh.

sudo iptables-save | less

There will be a lot of extraneous rules but the ones to focus on will be in the INPUT chain and pertain to port 22.

Looking at sshguard in Ubuntu, it looks like the defaults should work. But check iptables to be sure that attacks are getting blocked, if you are still getting probed.

Sometimes it helps to lookup the netblock owner for misbehaving hosts and fire off a polite e-mail to the contact person with a few sample log entries.

[Lars Noodén]

When on the LAN, you aren't going through the router at all, but are connecting directly to the server. When outside the LAN, you're going through the router. So it could still be the router. Are there other machines on the LAN connected to the router? Is there wireless on the router?

The LAN has its own router, but that one seems not to be involved. If there is a problem with the router, it is likely with the next layer out or more likely it is another host on that layer because it looks like the external address is getting spoofed. Perhaps in the networking subforum someone would know what the best action is.