This might be a a little out there on the internet but even today a lot of us are not aware of the smallest measures one can implement to secure themselves from the various red team attacks. Sometimes its the smallest of things that we overlook end up getting us compromised. The whole idea of this blog is to put out my learning for others. For some these posts may be something they have already implemented, for others they may be something new and would like to try and experiment around with.
Look under the “BlueTeam” category to find more defense practices I will be experimenting with. They might just be useful to you.
This post in particular was actually a lesson learned from when I participated in the Department of Energy’s Cyber Defense Competition. I had secured my SQL database server with everything I knew except for checking whether the SHH instance I had secured was the only instance running or was there another. What eventually turned out was that another instance of SSH was running on a different port number with a simple password and I failed to scan for it. The red team took the advantage and was easily able to brute force the password and get a hold of my server.
WHY am I writing about it ?
Because SSH is the first thing we use when we want to securely connect to a remote machine, usually to perform maintenance activities. Even if not that, port 22 (port on which the service runs) is usually one of the first ports that gets hammered when you connect to a public network, open wireless access point. If you go and check your logs you will notice entries of failed authentication as a root user trying to connect on your machine on that port when connected to such networks.
Plus, there are many users out there who have windows based machines and use PuTTY every now and then to access their server machines but don’t know how to go about setting up key based authentication using it.
Benefits of using keys
You can setup a strong passphrase instead of a password along with the key you use to login.
An attacker would have to gain hold of your private key first before they can even attempt brute forcing the passphrase.
The key based authentication provides a better assurance to the user that the server is actually the server they intended to connect to. A malicious user cannot pose as a legitimate server without obtaining that server’s host key, since you would otherwise be warned that the host identification had changed.
If you decide not to setup a passphrase, it provides you a direct login to the terminal without prompting for a password and you can start executing your commands.
BUT, a few things to keep in mind
The private key that you create during the key creation process must be kept secret, and no one else except the owner ( YOU ) must have access to it. If you loose the key, you basically lost your identity and anybody who now has it can gain access to the server machine pretending to be you.
Keep in mind that this process is not very scalable. Its OK to perform this if you have a small team of Admins in charge of a particular server, but when it comes down to a large team the key distribution can be a cumbersome task.
NOTE: THIS ARTICLE IS FOR USERS USING WINDOWS OPERATING SYSTEM AND PuTTY TO CONNECT TO THEIR LINUX SERVER.
The below mentioned steps will help you generate a key pair and use them for authenticating an SSH session with your server. I have also covered steps on how to disable password based login and root user login.
If you don’t already have PuTTY on your machine then go ahead an download it from here.
Install the PuTTY package. Once done go ahead and run PuTTYgen. This is a PuTTY utility that will generate key pairs for you.
It will look something like this.
Before you start the key generation process, look closely at the bottom right. The numerical value signifies the number of bits that will be present in the generated key. My suggestion would be to go ahead and do 4096 as a larger key is difficult to compromise.
Go ahead and click generate.
You would have to keep moving your cursor on the screen as the keygen introduces entropy by doing so during the creation process.
Once complete you will see other options for your generated key pair.
Here you can set the passphrase for your keys. Create a strong passphrase.
You can go ahead and save your private key and public key. They will come in handy at a later stage, but make sure you copy the public key generated as text from the section shown below. COPY EVERY SINGLE PART OF THAT TEXT. Paste it in a text file for the time being as we will be adding this public key to our server.
Now log into your server as which ever user you normally do. In my case I am logged in as “reduser”, ironic isn’t it, and make sure you are in the home directory.
Create a “.ssh” directory and change the permissions on the directory. Once done with that navigate inside the .ssh directory. The commands are in the screenshot.
Once inside, create a file “authorized_keys”, and paste the public key that you copied in it. To create the file execute the following command
nano authorized_keysNow right click inside this file and this will paste the text in it. “ctrl + o” to save it and “ctrl + x” to exit.
Now change the file permissions of the authorized key file that you just created by typing
chmod 600 authorized_keysYou can verify the permissions by executing the following command
ls -ald .ssh .ssh/authorized_keys
Now what you’ve basically is done that you added your public key to the user “reduser” (different in your case) on this machine and now you would need your private key every time to log on this machine for this specific user.
To use your private key, open PuTTY and navigate to the “SSH” option on the left pane. Expand it and select the “Auth” option.
On the right side you should see the area where it will ask you to select the private key for authentication. Browse to the folder where you have stored it. Now select the session option on the left pane to go back to the main screen and create your session by entering the IP of the server machine. This time when you create the session, you will notice that on the terminal it say’s “Authenticating with public key xyz” and will prompt you for your passphrase.
Enter the passphrase and you are good to go. Had you not set the passphrase, you would only be required to enter the username and would then be able to execute the commands on the machine.
To further secure the machine, we will disable root login and password based login on the machine. This will create a complete dependency on the keys to access the machine.
Switch to super user by executing “sudo su” and start editing the “sshd_config” file
nano /etc/ssh/sshd_configNow make the following changes for the settings as shown below.
Once done then exit out of the file and execute the following commands to restart SSH service.
sudo service ssh restartor
sudo restart sshYou now have a server setup which does not accept root logins, no password based login and the only way to now login is through the use of keys.
Hope you enjoyed reading this article. 🙂
SecureSeed 
Leave a Reply