If you are working with AWS Public Servers, then one of the main concerns is the security of your public servers
– If your company has VPN configured, then you have a fixed set of IPs that you can whitelist in the Security group of Webserver – also if you are in the company network, the company may have a list of static IPs with them, which you can whitelist in Security groups
– but If You don’t have VPN, you are not in the company network, you are working from home, then there’s a rare chance that you have a static public IP address which you can whitelist, in this case, every now and then adding new IP of your team’s members can be a cumbersome task that you want to avoid and thus you open all internet traffic to that webserver which is a big security threat
In all the above cases, how do you achieve an extra layer of protection to your servers to prevent them from unauthorised access
Here are some tips that you can follow
1. Configure Strong Password
Don’t use “admin”, “user123”, “root” etc. easily hackable passwords, these can be guessed easily and thus unauthorized access possibilities are high
Use a strong password with a minimum recommended length of 16 characters, including special characters, numbers, upper case, and lower case letters
2. Make multiple Users
Don’t share the same username and password to all the developers, make individual users for all of them, thus only that person has access to his/her password and you can even track which user’s credentials was hacked if something happens
Don’t use the same key file/password with all of them, make them create their own password
3. Only give required minimal access
Figure out what all minimum access is required for each user and only give minimal access
avoid giving admin/root/Sudo permissions if not required
4. Enable MFA on each account
Adding Multi-Factor Authentication is an extra layer of security that you must add.
Virtual MFA can be added with Google Authenticator [iOS and Android] which can provide you new 6 digit code in addition to password authentication
Let’s see how to configure MFA on your SSH Server (Ubuntu)
SSH into server using root credentials and run the following commands
2. Run the following command to set up MFA on Root user
google-authenticator
You will be prompted with the following questions
Do you want authentication tokens to be time-based (y/n)
Select yes and press Enter
Next, you will be prompted with QR Code and Secret Key – Scan QR code using “Google Authenticator” App on your [iOS and Android] – Or enter Secret Key in the App using “Enter a Setup Key”
After this, you will also get “Emergency Scratch Code”, Save it at secure and different place then your mobile, If you lost your mobile, these codes can help you login to the system as backup
Next, if you have successfully scanned this code, it will ask you to add this file as below
Do you want me to update your "/root/.google_authenticator" file? (y/n)
If you select yes, it will save your all current selections in a file and also will add your secret codes for backup purposes.
Select yes and press enter
Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n)
This option is important because even if someone gets your secret OTP, they won’t be able to log in using the same code after you do.
So press yes and enter
By default, a new token is generated every 30 seconds by the mobile app.
In order to compensate for possible time-skew between the client and the server,
we allow an extra token before and after the current time. This allows for a
time skew of up to 30 seconds between authentication server and client. If you
experience problems with poor time synchronization, you can increase the window
from its default size of 3 permitted codes (one previous code, the current
code, the next code) to 17 permitted codes (the 8 previous codes, the current
code, and the 8 next codes). This will permit for a time skew of up to 4 minutes
between client and server.
Do you want to do so? (y/n)
Here, if you are sure that your authentication system has nice synchronization and you want to avoid using old MFA,
You should go ahead and press no
But, if you sometimes need to pass this OTP to other users as well, for debug purposes, time-skew can be an issue
You should press YES in this case
If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting? (y/n) y
Press YES and next, it will implement brute-force protection, thus you can only log in to terminal only 3 times in every 30 seconds
3. Configure SSH to Use Google Authenticator
Now, let’s tell SSH about this google authentication and force it for all user attempts
vi /etc/ssh/sshd_config
Edit following lines in the config
ChallengeResponseAuthentication yes
UsePAM yes
Save and Exit
Now, edit PAM config
nano /etc/pam.d/sshd
Add below-mentioned line
auth required pam_google_authenticator.so
Save and Close the file
Now restart sshd Thread using below mentioned command
systemctl restart sshd
and don’t close the current terminal
4. Now, let’s try and enter into the server using newly set up MFA, in a separate tab
ssh root@IP
// It will prompt for password
// If you enter correct password, it will prompt for Verification Code
// Enter MFA code from Google authenticator app on your phone
If you are able to login to your system now, Congratulations, you have successfully set up MFA on your Server
We hope you liked this article, share it with your network and share your feedback in comment section below
