New Security Plans

Due to repeated problems with hackers on servers at my day job, I’ve developed a new security plan that I’m going to share in a second. First, a little background, and then I’ll list my requirements that I used to develop the plan.

First, we have no official system administrator, and we have 15 or more servers right now, all running CentOS 5. No one really has time to do everything that should be done to keep them up to date and secured. I’ve made loud noises about this for some time, but for various reasons, nothing much has been done about this.

So, my requirements for the new security setup are: 1. Extremely low maintenance once it is in place. I understand that updates are important, but we don’t have someone to do that full time. 2. Because of that lack of personel, it should reduce exposure of possibly vulnerable services as much as possible. 3. Simple to work with and update as needed.

I did some research, and settled upon the following security ‘layers’ if you will.

First layer: Cracklib configured to require much more secure passwords. Most if not all of our compromised servers have been caused by weak passwords on key accounts.

Second layer: SSH daemon configured to not allow remote root login. There is no reason this should be necessary.

Third layer: IP Tables to lock down system so that only ports that are required for the purpose of the server are available publiclly, and all other ports are only open to the systems that need them. This includes locking the SSH and cPanel ports to only be available by default from the main office network, and any static home IPs of workers.

Fourth layer: Port Knocking daemon set up to give the ability to open the SSH port as needed from other locations. I’ve set it up with a 10 port sequence randomly generated from the 10,000 – 49,151 range, and randomly selected as TCP or UDP. Even at only 10 ports long, there’s 8.66 × 1048 possible sequences, which is plenty secure, when in combination with all the other layers. When the knock sequence is detected, it opens port 22 to the origin IP for 15 seconds, and then closes it again.

Fifth layer: DenyHosts daemon set up using global pool of blocked hosts to keep anyone who somehow happens to get through the port knocking from being able to bruteforce the SSH passwords.

I’ve already implemented the five layers above on several servers, and tested them for a while. It seems to be working flawlessly so far, and it should make the servers much more secure. As part of the implimentation process, I have mandated that we re-install the OS on the servers, to make sure they have a clean system with no backdoors built in. I don’t think there’s much chance of someone having a back door in place that could compromise this, but I’m not taking the chance.

If you have any further suggestions, enhancements, or questions, please let me know. I’m always willing to look at improving this plan further.

%d bloggers like this: