Security is fun

Some useful but perhaps not well-known tools for improving security in your network

I was suprised to notice at the last SLUG meeting that Anchor was in the minority with the security software it runs, so I'd like to take the opportunity to mention some tools that we use at Anchor on our dedicated servers that helps us keep our level of confidence high, but our level of interaction low. If you're like me, you hate doing the same thing twice. If you're like me, you know that computers love doing the same thing over and over again. Here's some tools that we've found that hide the tedious and keep us focused on the interesting things.

Osiris

osiris is an IDS similar to tripwire in functionality, but in my mind much easier to use, less annoying, and more reliable. Osiris runs a scan agent on each machine in your network, and a management agent on a trusted server somewhere on your network. Periodically, the management agent asks the scan agent to scan the system and report back the results. The management agent compares these scan results with its database, and if there have been any changes to the system, the management daemon will alert you by email of the changes. The configuration for the scans are created on the management server, and pushed out to each of the client machines when required. This means that we don't need to update and sign the scan configuration for every machine in the network manually (and if you're doing the right thing with tripwire and using a separate local passphrase for every machine, this can take a very long time with a network of 10 or more machines) The scans themselves are modular: there are modules for (as you'd expect) the filesystem and all file attributes, but osiris also includes scanning of loaded modules (on Linux systems) and scans of the user database. There are some other modules on the website, too. When a change is detected, and you wish to approve those changes, osiris provides you two ways to do it: through the management interface on the command line, or in your browser. When configured to do so, the email alerts from the management daemon contain URLs to the management daemon's internal http server so you can easily click-click-click to update a machine's scan database.

If I may pull a number from my nether regions, I'd say we've seen an order of magnitude increase in efficiency and reliability of this type of security check since switching from tripwire to osiris, as the process of enrolling new machines into the system as well as the continuing process of checking the results has a much lower overhead and is far less tedious and mundane -- and by reducing the mundane and repetitious, we can reduce the likelihood of human error.

cfengine

I've talked about cfengine before... but it's just an automatic configuration tool, right? How can it help? Well, I'm glad I asked! There are a few parts of cfengine that can check for anomalies in the system and alert you when it thinks there are suspicious things going on. The SuspiciousNames variable can be set to the common names of some rootkit file and directory names. FileExtensions warns if a directory name encountered has a suffix that makes it look like a filename. But the real power of cfengine when it comes to security is the ability to build new machines locked down to your standards, at install time, with no additional effort. After a while, cfengine will be doing things like disabling root logins via SSH, locking down service access in tcpwrappers, testing for and disabling all the services that distributions turn on by default, and setting up configuration files for individual services just the way you need them. Even existing machines will be updated to a more secure version within minutes of you learning about a feature and adding it to the configuration. Over time, your cfengine inputs will develop into a large database of security checks and default configuration settings that are tuned to your environment and that keep your systems all behaving and running just as you expect them to.

filtergen

filtergen is a tool for generating firewall rules from a higher-level language than the syntax most firewalls use: just like a compiler turns a computer program from human readable language into machine code. The filtergen language allows you to group rules into blocks, so common elements can be collected together to make your rules readable.

# a simple filtergen filter description
eth0 {
    accept;

    # allow connections from the network monitoring systems
    monitor {
        snmp;
        osiris;
    } accept;

    # allow connections to services
    accept;
};

The above is an example of a trivial packet filter on a webserver; we allow ICMP traffic, web, and SSH from anywhere and allow SNMP probes and connections to the Osiris scan agent from the monitoring stations. We have a common set of rules that is used on all machines that gets copied out by cfengine, and then a set of machine-specific rules gets included, which means that we can ensure that all machines do what we expect and that each of the client-specific changes to the firewalls are clearly documented and easy to find. A more complete example of the kind of filters we use follows:

# allow all on loopback
{ accept;

# the public interface
eth0 {
        accept;

        # reject auth instead of dropping it so that services
        # requiring it don't timeout
        reject;

        # ntp
        accept;

        # anchor internal maintenance address
        maint-addr.incl } {
                # ssh access
                source
                    { anchor-priv.acl };

                # monitoring
                monitoring.acl } {
                        # nagios nrpe daemon
                        5666;

                        # snmp from nms
                        snmp;

                        # ntp monitor
                        ntp;
                };
                # osiris scan agent
                2265;

        } accept;

        # additional per-host include fragments
        input.d

        # unconditionally drop all other packets, do not log
        drop;
};

eth0 {
        accept;

        maint-addr.incl
                 host-addr.incl } {
                # DNS
                domain;

                # outbound mail
                smtp;

                # cfengine
                cfengine;
                # time
                ntp;

                # RHN up2date
                accept;

        # additional per-host include fragments
        output.d

        drop;
};

The contents of the input.d and output.d directories are files with rules in them describing a service that the machine provides, e.g.:

# input.d/web
accept;

filtergen does all the hard work of turning that description into (in our case) iptables commands, and a convenience command fgadm makes short work of checking the input for errors before reloading the firewall. If you're going to start using this tool, I strongly recommend the fgadm(8) manual page for a neat way of reloading firewalls so you don't shoot yourself in the foot.

So, we have a set of rules that is common between all machines, and some extensions that are documented well enough that we can see what we've got in place and what our clients require, which means we don't have to bust our brains trying to translate the raw rules in order to update the firewall, which means we're less likely to break the firewall overall, and the process of reloading the firewall prevents us from locking ourselves out I've recently taken maintainership of this tool over as we're using it so much (and I'm indebted to Matthew Kirkwood for his work in the past).

Keywords : linux security software systems administration defence in depth osiris cfengine filtergen