Alternatives to Bastille Linux: system hardening with Lynis

System hardening with Lynis

Many people used Bastille Linux to harden their Linux systems. Unfortunately the website of Bastille seems very outdated, including the tool. This resulted in people searching for a great alternative to replace this tool. We found the alternative by actually combining different solutions, being more powerful. Security automation is hot, so forget Bastille and do it the right way.

Automatic hardening makes sense

Most system administrators can’t keep up with the new technologies and security threats. It is simply to much to investigate everything and stay up-to-date with the latest software. Besides that, the existing systems often need management, even years after the initial software was released.

Automatic hardening, or security automation, reduces the effort on the part of the system administrator. The tooling is ready to go and can tighten up security controls on the related system. The big benefit is that running a tool is quick, does not require much knowledge and at least provides additional protection.

Why it does not..

Tools make people lazy, sometimes even uneducated. Without understanding why a change has to be implemented, it might give a false sense of security. Then there is the risk of crippling the system by implementing a security control without proper testing. Additionally there is the fact that most systems are not equal, so exceptions might be applicable or needed.

The alternative to Bastille Linux

Lynis (Linux/Unix auditing tool) screenshot

Screenshot of a Unix security audit performed with Lynis.

Lynis is not a hardening tool, but helps with hardening. Instead of just changing configuration files, it will perform an in-depth audit of the system and show the related findings. The administrator then can determine what controls are appropriate to be applied and create a custom automation script. This can be done via a normal shell script, or by using configuration automation tools like Cfengine or Puppet.

The big benefit of using an auditing tool is the flexibility and support for different operating systems. Often companies use different Linux distributions, resulting in a tool only support one or another. When it comes to hardening, each system has it’s own minor differences.

Security automation

By combining the auditing and configuration automation, we have security automation with continuous monitoring. Both the automation tool will check for inappropriate conditions and so will the auditing tool. While it initially will take a little bit more time, it will outperform the benefits of an automatic hardening tool. It will give security insights for the system administrator(s) and includes checking the configuration on a regular basis.

For people who are known to the Plan-Do-Check-Act cycle, they will recognize the steps. It starts with your goal for hardening and planning the initial audit (Plan), up to the implementation (Do), checking for effectiveness (Check) and act upon new findings (Act). This way of working is more in line with security, being a process and not a product. It enhances security awareness and let people act upon new findings, instead of the “fire and forget” of a tool.

Conclusion

Bastille Linux is a great tool, or maybe we should say, was a great tool. Fortunately there are better alternatives nowadays, by combining tools and leverage the strengths of each tool. The combination of an auditing tool and a configuration automation tool, will provide more benefits. They include better educated personnel, more control over the implementation, continuous monitoring and working according to a process, enhancing security over time.

 

Did you find a better alternative for Bastille Linux? Share it in the comments!

facebooktwittergoogle_plusredditpinterestlinkedinmail

PCI DSS (v3) for Linux: Auditing application processes (A.1.2.a)

PCI DSS (v3) Linux: Auditing application processes (A.1.2.a)

A.1.2.a Verify the user ID of any application process is not a
privileged user (root/admin).

For Unix and Linux based systems, processes should run as a non-privileged user where possible. However to be able to start, a process is usually started with root permissions (uid 0). This is required to open the required sockets (e.g. bind to port 80).

After the initial start, the process drops its privileges by switching to another user. In some cases there will maintain one master process, which is started with uid 0 as well. This process is responsible for the creation of child processes, not for handling interactions with users or processes. You can consider this as an administrative process. The child processes do handle

To gather a list of application processes running under the context of root, we can query ps and list all related entries.

ps -ef | grep "^root"

Another way is to combine a few commands and only list the interesting processes, like this:

ps -ef | awk '{ if ($1=="root") { print $8 }}' | grep -v "^\[" | sort | uniq | egrep -v "^(\-su|awk|egrep|grep|ps|sort|uniq|su|sudo)"

With this command we query ps, filter out application processes running under the context of root and hide commands which are not interested.

Usually this will still be a list of several items. Every process which has a master process, which have at least one process running under the root context. This is acceptable behavior as explained before. Other processes have to be analyzed by hand, to see if they are properly configured.

This information is provided as guidance to our PCI plugin for Lynis.

facebooktwittergoogle_plusredditpinterestlinkedinmail

Security Automation for Linux: Are Humans Still Needed?

Security automation for Linux: Are humans still needed?

The problem with humans is that they are smart, but slow. They can’t react to simultaneous events and aren’t always working. Besides that, they make mistakes, have to deal with budgets and internal company politics. Information security is impacted by these effects as well.

As you might guessed, the solution is in automation. SCAP (Security Content Automation Protocol) is one of the answers. Especially the automation part is interesting, as it can improve quality, decrease time efforts and remove the “boring” work.

SCAP is using predefined templates, stating how a machine should look like. Not only can SCAP check a state of a configuration item, it can also push the preferred value. The problem of unsecured systems is over, right? Not really…

Pros

Automation is key, especially in this time where every minute equals a lot of money. SCAP is the ultimate method in automating as much as possible. Together with your configuration automation (e.g. Cfengine or Puppet), setting up your security defences via SCAP is great.

SCAP already uses a predefined consensus of what is “secure”, reducing the amount of preparation work. System administrators now only have to activate the related template, run the SCAP toolkit and they are done.

Standards like SCAP also provide a better security awareness for companies. After all, it are the experts who think about the subject and share it with the world. In this case the people from NIST and the contributors to the CIS Benchmarks.

Cons

Unfortunately SCAP is not matured enough. It isn’t well known, nor at the stage yet, where it is accessible for most of the administrators. The templates to check (and harden) systems are very specific and will only work for those operating systems, including the specific version. When running a different version, you will have to change things manually, or wait for an update.

Achieving consensus

So if your company is not the government, you will run most likely the newest versions. However it takes time for the SCAP policy writers. They have to come to a consensus and draft a hardening proposal. With all the differences between Linux distributions, it is hard to come up with a clear template which works for all of them.

Dealing with exceptions

Not all machines are the same, which usually results in exceptions. Such an exception might be needed due to the role a system has, the particular business owner or application running on the system. Full automation (including alteration) is not always preferred, as it might break business critical machines. That is unfortunate, as these systems benefit the most from hardening. So also on this point it may be inappropriate to use full automation.

Conclusion

Security automation is great, but we will always need people. One of the protocols to implement security automation, SCAP, is not matured enough. Right now, the combination of a good auditing tool, together with a configuration automation tool is much stronger. It saves you from the hassle of waiting for new templates, gives you ultimate flexibility and still uses a lot of automation. Combining the automation of these tools with the intellect of people and you have a much better solution.

 

facebooktwittergoogle_plusredditpinterestlinkedinmail
« Older Entries