Improving Linux Security with DevSecOps

Ask people who run IT departments these days what keeps them up at night, and they'll probably tell you it's security—or the lack of it. With the explosive growth of malicious attacks on everything from hospitals to Fortune 500s, security—not hardware, software and even staff—is what currently makes life miserable.

That's why organizations of all sizes are looking to change fundamentally how they do security. It's no longer a single team's job to make sure systems are secure and internal auditing is good enough to identify and mitigate attacks. Today, everyone is responsible for security, which is the guiding principal of DevSecOps.

Just as in DevOps, which aims to speed the development of software by improving collaboration and balancing the competing interests of operations teams and developers, DevSecOps seeks to get everyone thinking about security together and up front. Trying to bake in security after systems are built and code is deployed is simply too late.

Steps That Make for a More Secure Linux Environment

Fortunately, you can make things more secure by design by using some common tools and practices. You don't need a "Security Initiative" to lower your risk of breaches and hacks. You can start small, share what you know and lower your risks today.

Establish Baselines

One of the best ways to improve security is to know what you have in the first place. Security experts lament the fact that most organizations, many of which have grown organically over time, haven't taken the time to define standard rules for their systems that can be repeated and shared. For example, good baselines will include:

  • Machine-level firewall rules: firewalls aren't just for the edge. You should deploy them at the machine level for bare metal, VMs and containers that are off-premises and on. One size doesn't fit all, either. Web server firewalls should look different from application server firewalls. If that sounds like an overwhelming challenge given the number of servers you manage, you need to think seriously about automation.

  • More deliberate port rules: which ports are open and closed to whom and to where? Is port 22 open on all your systems? Does it need to be? If it is, is access limited to certain subnets?

  • Limit access: which users and groups have access to which systems? Do developers need access to all your dev servers or just a subset? Which machines have access to each other? Web servers probably should be able to talk to your database servers, but do they need to talk to other application servers?

By asking a few routine questions like this, you can begin to define and implement some solid baselines. Share them on a wiki using MediaWiki, TikiWiki or PmWiki to make updates a snap. Wikis make documentation easier, which makes adoption and use easier—and more effective.

Machine-Level Firewalls

You can deflect a lot of bad activity by setting a few good firewall rules—even on systems that don't see the outside world. After all, not all security problems come from the outside.

Iptables is robust, ubiquitous and relatively easy to manage, even from the command line. So, if you want to give only a single specific subnet shell access to your Linux servers, you can add a rule like this:

# sudo iptables -A INPUT -p tcp -s --dport 22 -j ACCEPT

If you're running IPv6 (and many Linux distros do by default), be sure to install iptables-persistent and add the same rules. It doesn't make sense to lock down one protocol and not the other:

# ip6tables -A INPUT -p tcp -s fe80::e65:2f8e:4f60::1/128 --dport 22 -j ACCEPT


John S. Tonello is Director of IT for NYSERNet, Inc., in Syracuse, New York. He's been a Linux user and enthusiast since he installed his first Slackware system from diskette 20 years ago. You can follow him @johntonello.