The sheer number of tasks involved in building out automation infrastructure for a new organization never ceases to amaze me. One of the most often overlooked groups of tasks, however, is security. Though I am in no way a security expert, I know there are some basic steps we should take to protect ourselves and our precious systems.
I also know that not everyone who administers RHEL systems has an extensive background working with Linux. If, like me, you’re normally a Windows admin, yet you find yourself having to secure a RHEL system, fret not. Here are some tips for adapting what you already know about Windows security best practices to RHEL environments.
(Some of) The Basics
For our purposes here, I’m going to run through three things that I would do quickly on Windows and discuss their equivalent on RHEL. We’re in no danger of this becoming a comprehensive guide. As far as starting points go, it should be fair enough.
- Software Updates
- User/Group Isolation
- Port Closings
Software Updates
Windows is of course notorious for its (at times) inconvenient update schedule and process. Still, as painful as it may be to some people, it’s much better than the alternative of not getting any updates at all. Keeping your software and operating system up-to-date are easily one of the first lines of defense in security. No software lacks vulnerabilities. It is simply a matter of time and effort before they are found.
Thankfully, Red Hat has its update game together. It not only comes with the Application Installer to notify you of available updates—it will also send notices straight to your inbox as soon as updates are available for various pieces of software relevant to your installations. To be honest, the information is almost overwhelming as a part-time user of RHEL, but I know the main audience of system administrators will need and use this information to do their jobs well.
Sometimes you will install software that doesn’t seem to register with the Application Installer. Many times you’ll still be covered if you do a yum upgrade -y periodically. Beyond that, though, as seems to be the case with how I installed TeamCity, you will simply need to be sure you have scheduled time periodically to upgrade your software and keep things safe.
User Isolation
When installing software, especially services on a server, isolating the service into its own user account offers many benefits. The biggest is that it limits the amount of information available to the service. This keeps your other information safer in case of a breach (see “Software Updates”), which is something we can all celebrate.
In Windows, an installed service will typically be set up to run under the SYSTEM account by default. This is easily changed via the Services management console with a couple clicks of the mouse, but how does this work in RHEL? In many cases you won’t even have to worry about this, as several of the services I’ve installed via yum took care of setting up their own user accounts and groups automatically.
For those services that might not (maybe one that you’ve created yourself), the process will involve two extra steps around your software installation.
- Create a new group and user:
- groupadd newgroup
- useradd -g newgroup -p ****** newuser
- The -g flag indicates that newgroup should be the user’s primary group
- The password should obviously not be ******
- After installing the software, create your own init script that uses sudo to change the user account with which your software runs:
- exec sudo -u newuser /usr/local/init/mysoftware
These two steps will ensure that once your service is started, it will run underneath your newly created user account. Furthermore, you can utilize the new user group to control file/folder access when necessary.
Thus far, I have had success creating a secondary group for development purposes, and adding it to both my personal account and the TeamCity account I utilize. This way I can change group ownership using chgrp to the ‘intermediary’ group and give access to both myself and TeamCity without requiring elevated permissions.
Port Closures
The final stop on our journey is arguably the easiest in both worlds (at least these days). Both Windows and RHEL come with firewalls that can be used to limit what traffic makes it to your software. This is crucial for limiting the number of areas to which you are vulnerable from the Internet. More advanced firewalls can be used to further increase that protection.
Both RHEL and Windows offer graphical and command-line options for managing firewall rules. By default, most ports are closed to the outside world in both operating systems. Typically you will want to preserve this behavior, only opening ports to your local network for services like TeamCity and build distributions.
Conclusion
RHEL provides comparable (if not superior) options for securing an environment for any administrator willing to learn. In addition, Red Hat (the company) offers extensive training on hardening RHEL servers to help administrators stay on top of the constantly changing field of systems security. The more you’re able to learn, the easier time you’ll have keeping your CI infrastructure safe from prying eyes or malicious fingers. Good luck!
Andrew Male
Andrew Male (@AndyM84) is a senior engineer at an enterprise development company in Boston, MA. Andrew has been programming from a young age and is entirely self-taught; he has spent time in many corners of the programming world including game/VR work, agency work, and teaching development to students and adults alike. He spends most of his time working on architecture design and pursuing his favorite hobby—physics.
