I did end up finding out a solution that I believe is a whole lot better than what others tend to do. I just simply don’t like the idea of setting it and forgetting it because I simply do not believe that bad actors will not be able to find their way into some system. I have thought hard about how I would go about this. Keeping in mind that there is room for improvement and also other key features that I believe are still missing from my security provision for Ansible. The future features require a bit more thought and self study that will simply come by with time.
After reading a lot about this topic I found out that a lot of Sys Admins actually don’t do some of the steps that I would believe are detrimental in securing an automation system of this capacity. Many truly believed that if they had a Key Based Authentication they would be completely fine because how could a bad actor get into a system. I understand that maybe the Ansible server could really be cared less about then any other server. But hear me out, if the bad actor could then create new playbooks to run inside in all of your servers that are being managed by it….. does that not cause any concern? All I am trying to say is that there can and should be more hardening done from my perspective. Security features that are added by me are steps: 2-5
I have shown a diagram above that shows a brief layout of how the automation process will be implemented to new servers. Now some details are redacted for security reasons but this is the general layout that I believe should be a minimum. With all of these security steps in place I believe would definitely cause frustration, increase time spent, and signal a Sys Admin that shady figures are lurking. Even if this delays an intrusion by an hour I believe that’ll be enough time to just shut down the Server/VM if necessary to save the whole infrastructure of a big organization.
For example Sophos a very well known security company does research about thousands of attacks to try and migrate as many of them as possible for their customers. They also release some worth information that I think would agree with some of my potential security implementations. The article mentions that an attacker that has gained access to a system on average dwells about 15 days overall, 34 days if there is no ransomware, and 47% of attacks start with a vulnerability exploit. After knowing this information it makes me feel a bit better about putting security provisions to replace and renew keys at the rate that I am because even an attacker got in and took a few days to come up with a plan he’d lose access to that system. He would lose access via key based auth and due to security patches being automated. With the “sshd_config” file being monitored very often it would mean that even if the actor had created backdoors It would write over any previous configurations made by others.