Improving Linux Security with DevSecOps

Source – linuxjournal.com

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 192.168.1.0/24 --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

Users, Groups and the Principle of Least Privilege

Everyone knows how to add a user quickly to a Linux system, but how often do you take the added step of creating groups to manage those users’ privileges? By adding users to groups and giving those groups permission to certain services, directories and files, you can manage access—and inevitable changes—with more control. From a DevSecOps perspective, you can share information about the groups you create with other teams, which helps them understand your methods without having to guess.

Remember also that if someone doesn’t need access to a system, don’t grant it. Add only the users you must.

Gain Greater Control with Automation

If you’re managing a handful of servers, you can get by with manually making updates, adding users, setting up firewalls and the like. But once you get beyond 25 or 30 systems, you really need to get serious about automation.

Tools like Puppet, Chef and Ansible can help you there. Each works in a slightly different way, but the underlying principle is the same: automate away the routine stuff, and make your systems more consistent and transparent.

Puppet uses manifests to define the desired state of any host you want to manage. Because you define what you want—these firewall ports open, those closed; these users present, those not; these services running, those not—you can create secure systems that stay that way. Puppet tools like Facter and Resource also provide details about your systems that allow you to use regular expressions to define different configurations for different servers easily.

Lumogon is a powerful new tool that gives you an amazing array of data about your Docker containers, providing clean JSON reports or publishing reports to a private web portal. If you’re worried about the darkness inside containers, Lumogon can shed a lot of light.

Greater Control with Data-Mining and Visualization Tools

Feeling more confident about security can be a matter of getting a better picture of what’s happening. Sure, the command line can give you some nice output in your shell, but graphical visualization tools take it to a whole new level of actionable intelligence and sharing.

Splunk users revel in the depth of machine-generated data it can monitor and dig into. Its reports are great for sharing as well, giving different teams data they need—and need to think about.

Puppet Enterprise offers a number of real-time visualization tools, including “node graph”, which shows the relationship between all your managed nodes. Its basic dashboards are anything but, giving you a view of problem nodes at a glance.

Conclusion

If security issues keep you up at night, take a few simple steps toward changing how you think about security in the first place. Step back and consider how everyone can participate and be engaged, and think about the tools and practices that can help. If you’re better able to share information, establish repeatable practices and engage all the teams in your organization, you’ll have better security and be better prepared to avoid problems that can really ruin your day.