Ansible Role and Playbook for SSH Hardening using SSH Configuration and Fan2Ban
Where companies/industry use ssh in day-to-day activities:
1. log in to remote systems
2. secure file transfer
3. secure backup and copy
4. machine-to-machine access and communication
5. secure command execution
6. protect privileged accounts
7. network traffic
8. tunnel applications
The situation of Industry!
We all know what ssh protocol is and for what it's being used. The above mentioned are some of the use cases of it. We all use ssh in our day-to-day activities and we don’t even care about the security features of such a protocol. There are many things that can be configured using only the configuration file of ssh but, due to lack of interest and awareness of cyber attacks on such protocol is not so common in people. The industry tends to focus on business rather than security measures, hence there is an increase in security breaches. They are not wrong from their perspective, as they have to focus on the increase in profit and market value and production of their company, hence they have to hire a security specialist. Tho minor details are always left out. One such thing is the ssh protocol.
What is the situation of the industry?
1. Poor management of services, hence no record of who has access to what systems.
2. No tools to remove unused or unauthorized keys
3. No methods to restrict access to private keys
4. No visibility into user activity during SSH sessions
The main issues over and above all:
5. Manual setups + maintenance = costly errors
When it comes to ssh we have to be careful about the following things:
1. Embedded SSH Keys in application scripts
2. SSH Key sharing amongst the common group of people leaving behind a fingerprint in the network.
3. SSH Key rotation, sometimes it's tedious and even not done properly in industry.
4. SSH Key tracking of hundreds and thousands of servers running.
5. SSH Root access by default with not changing the by default password leads to a major security breach.
6. SSH Password login access is allowed, hence there is a clear chance of brute-forcing if we have a weak password.
Even though keeping these things in mind we usually make mistakes and sometimes just ignore doing so, basically doing it manually is highly prone to the cyber attack. So, we need something which can do it automatically and something which we can easily modify according to the use case. It will also be better if we can have extra, security in-depth for other services running.
So, here is the solution, we can use Ansible for such a use case. I have made a role and a playbook for the same. It will make some changes in the configuration file of SSH and even install Fan2Ban which will provide even protection over brute-force or DDoS or DoS over SSH. This solution is scalable as Fan2Ban can be configured to provide more security over other services with SSH.
I will demonstrate how to make and use this playbook, role is simple copy-pasting things according to the directory file. So let’s begin!
Creating Playbook for SSH Hardening
Understanding the configuration:
1. We will first, remove the Root Login access, and then we will disallow password login, doing so we are securing ssh by disallowing password brute force and if the user hasn't changed the default login password of the root, it will be secured.
2. Next, we will add a user if the clients want to add or else will use a pre-made user which the client has to specify in the variable file. This user will have sudo power.
3. Now, we will make an ssh key in the local system if the client wants and then we will transfer the key to the user-created or specified by the client. Doing, so we have secured ssh and we still can log in to the system via the user and do things with sudo power.
4. Finally, we will configure fan2ban to have extra protection over, brute-force on login using the key, and even DDoS and DoS. Behind the scene, by default, it will use firewall rules to block and unblock the users. We can change this setting if you know fan2ban but, whatsoever configuration is done by default is at its best. We can further configure fan2ban by editing the temple file and can give extra security to other services apart from ssh. This is the future scope of this playbook. Hence, it's tightly secured.
This is the variable file, which the client has to edit to customize the play. If the clients want to create a new user, they have to change the add_new_user to true and then give new_user_name in the ssh config variables. Similarly, if the clients don’t want to create a new user and want to use a pre-existing user, they have to turn the new user to false and pre user to true. Moreover, if the clients don't want to configure fail2ban they can give it a false. If the clients are providing new use, they have to type the password instead of shubham in the second last line. To rotate the key, you can tell key_rotate to yes. If the clients want to allow root login and password login they have to turn then to yes in the ssh config section. To configure fail2ban, we have the following variables:
destmail: where to send the mail if something happens.
sendermail: through which mail to send
sendername: name of the sender
mta: message transfer agent
banaction: which action to use the attacker, we have chosen iptables, you can check their page for more.
f2bsshfindtime, f2bsshmaxretry, f2bsshtime: tell us if anyone in 300 sec i.e. 5 min tries for 5 times will be banned for 21600 sec i.e. 6 hrs.
f2bsshignoreip: if you don’t want specific IP(s) not to ban then write it here.
These are our tasks which will run according to the var file that our clients will configure. Even its made idempotent on the user creation, file, and directory creation also. Hence, it is fully optimized for use.
This role and playbook will be perfectly working fine with all the versions of RHEL, Fedora, and Centos or any distribution associated with it.
Results:
Here, you can see the output of the role which, I have created, this works the same for the playbook also. Now, if you try login with a password to any user it won't allow it, even if you log in to root it will deny. If you give continuous 5 wrong attempts to the key login, it will ban you, until and unless you are listed in ignoreip.
🎫 GitHub: https://github.com/AnonMrNone/ansible-ssh-hardening
