Three major things happened that made it possible to compromise:

1. I received an OK from the higher-ups that indeed it would be ok to mandate that users who want remote access to our system have all their Internet traffic routed via the VPN.

2. The VPN configuration that was proposed is not that of a private group but the generic campus-wide VPN solution with ACLs to allow VPN clients to access our resources.

3. The generic campus-wide VPN service does *not* implement any outgoing restrictions, unlike the private VPN groups do. This makes it possible for VPN users to do whatever they want when connected, with the stipulation that it’s akin to bringing your personal computer to campus in terms of privacy.

This really is the best of both worlds (security, ease of use). The campus VPN service is super-simple to use and we restrict access to our services to VPN users instead of the whole Internet. While we don’t control who gets access to the VPN, the pool of users is MUCH smaller and at least semi-trusted by the organization. Thus the risk is greatly reduced.

I’m happy.

Related posts:

1. Remote Access Solution

The example is that of a very, very basic sudoers policy but the principles are easily extended to create much more complex policy. The general idea here is that we want cfengine to ensure that specific rules are always in place. Instructed properly, cfengine accomplishes this very well.

Warning: I don’t know anything. I’m just someone learning cfengine 3 and posting about it. If I’m wrong about something, let me know! If you find this at all useful, be my guest. That is all.

################################################################################
##
## FILE: sudo.cf
## DESC: Control /etc/sudoers file on various servers
##
################################################################################

bundle agent sudo
{

vars:

  "sudoers" string => "/etc/sudoers";

  "sudo"     slist => {
                      "%admin ALL = ALL",
                      "%sysadmin ALL = /sbin/mount",
                      "%devel ALL = /sbin/mount"
                      };

packages:

  Night::

  "sudo" -> "Security policy"
    comment               => "Ensure sudo is up to date every 24 hours (and only at night)",
    package_policy        => "update",
    package_method        => yum,
    package_architectures => { "$(sys.arch)" },
    action                => if_elapsed("1440");

files:

  "$(sudoers)" -> "Security Policy"
    comment      => "Append common configuration to sudoers",
    edit_line    => append_if_no_lines("$(sudo)");

}

As with last snippet I posted, the above does not even resemble a complete cfengine policy/configuration, just a small portion that can be contained in it’s own bundle. It can be put in a separate .cf file, imported by promises.cf and added to the bundle sequence, inheriting variables and classes! Also, just like last time I’m using cfengine’s built in interface for package management systems to ensure “sudo” is always installed via yum at night, every 24 hours.

What’s new here is file editing with edit_line and the use of iteration which proves to be very powerful in cfengine 3.

Editing Files

Editing files with cfengine is supposed to be easy but initially it seemed a bit awkward to me.

First you have the promise file promise:

files:

  "$(sudoers)" -> "Security Policy"
    comment      => "Append common configuration to sudoers",
    edit_line    => append_if_no_lines("$(sudo)");

Which makes some reference to the edit_line facility and what looks like a function name with append_if_no_lines(…).

Then you have the edit_line bundle defined elsewhere:

bundle edit_line append_if_no_lines(list)
{
insert_lines:

 "$(list)";
}

Which describes what “append_if_no_lines” actually does.

Of course I’m just learning cfengine and new things can often seem strange and scary but I am finally warming up to editing files with cfengine… I think. What I seemed to have initial trouble with was with the bundles necessary for edit_lines, as described above. The bundle within a bundle concept. The append_if_no_lines and append_if_no_line bundles I’m using are implemented in the cfengine std library, which is highly recommended so that you may avoid re-inventing the wheel a little bit.

For basic promises, to add or remove, comment or uncomments lines and the such there are good edit_lines bundles available in the stdlib. For other more complex or customized file editing, writing your own bundles will be necessary. Either way, understanding what a bundle is and how to create your own is key to fully grasping file editing and getting the most out of it. This seems obvious in retrospect but something I didn’t pickup instantly.

See the cfengine documentation for more about editing files, check the cfengine documentation. There’s waaaaay more good information over there and it’s from the cfengine team, not some random newb.

Iteration

Iteration is powerful mechanism within cfengine that harnesses the power of lists to express a large possible number of actions/operations with very little amount of code. When lists are used, single actions can be made to repeat for every item in a list by using the $(varname) syntax to refer to the list… which as it turns out is the same for scalar values! Funny that!

So cfengine allows us to define X different lines of code to ensure are in a file using only a single file: promise all with the same simple syntax as scalar variables? Brilliant!

A demonstration of iteration can be seen with the $(sudo) slist and the “Append common configuration to sudoers” file: promise. With this single promise definition, up to 6 actual promises are made because the $(sudo) variable is an slist. Each element or item in the list is iterated over in sequence and the promise is evaluated and acted upon, if necessary. The reason that up to 6 promises will be evaluated is the ifvarclass property of promise, ensuring the promise will only be kept if we’re in the context of the class… and looking at the promise to find out which class, we see another example of iteration using the $(sudo) list and the canonify function that turns a string into a class. Thusly, if the host currently running this policy defines all the classes that are tested by the ifvarclass iteration, 6 promises will be made. If the host defines 3 of the classes, then 3 promises will be made and so on, and so forth.

As a beginner, using lists and iteration effectively and creatively seems fairly important to getting the most out of cfengine 3.

Editing Files vs. Copying Files

In my previous snippet, I demonstrated how to promise to copy a file from a secure remote server if the local file does not match the server’s file in order to manage a configuration with cfengine. This time, I’m promising to add lines to a configuration file if they do not already exist exactly as provided.

This represents two rather different takes on policy. The first says: “The configuration must always be exactly like this file, byte per byte!” the second says “These lines must exist but I don’t care about anything else in the file”. The file copy method is what I would call hard policy and the second is soft policy. In the cfengine community solutions, they recommend managing sudo by copying an /etc/sudoers from a remote server. That way is great (just like my DenyHosts example) but this is just another way if you have a use case for cfengine not owning every byte of your configuration file.

Conclusion

Yeah, that’s about it. Enjoy.

Related posts:

1. Cfengine 3 Snippets Part 1: DenyHosts
2. Nanorcs: Ultrasimplistic Configuration File Revision Control
3. RHEL/CentOS, NFS and Firewalls

As part of my learning experience with cfengine, I’ve decided to start posting some of the code that I’ve begun developing in the hopes that by writing about it, I can learn better, faster and maybe even receive some helpful comments from readers along the way. Beware, I’m a cfengine newbie and so what I post here should NOT be copy and pasted into your environment unless you’re ok with the potential of wildly breaking things!

The first snippet of code I want to discuss is related to managing our DenyHosts configuration. As part of our “security policy”, I would like to ensure that every RedHat/CentOS system is running a properly configured DenyHosts instance. Here is what I’ve come up with so far.

################################################################################
#
# FILE: denyhosts.cf
# DESC: Install, update, configure and ensure DenyHosts is running
# DATE: May 2010
#
#################################################################################

bundle agent denyhosts
{

packages:

  "denyhosts" -> "Security policy"
    comment               => "Ensure denyhosts is installed once a week",
    package_policy        => "add",
    package_method        => yum,
    package_architectures => { "noarch" },
    action                => if_elapsed("10080");

  Night::

  "denyhosts" -> "Security policy"
    comment               => "Check for update to denyhosts every 24 hours (and only at night)",
    package_policy        => "update",
    package_method        => yum,
    package_architectures => { "noarch" },
    action                => if_elapsed("1440");

files:

  "/etc/denyhosts.conf" -> "Security policy"
    comment   => "Standard base DenyHosts configuration",
    copy_from => mycopy("$(g.confdir)/denyhosts/denyhosts.conf", "$(g.cfserver)"),
    classes   => cdefine("denyhosts_restart", "denyhosts_conf_copy_failed"),
    perms     => mo("400", "root"),
    action    => if_elapsed("1440");

processes:

  "python /usr/bin/denyhosts.py" -> "Security policy"
    comment       => "Define denyhosts_restart class if denyhost is NOT running",
    restart_class => canonify("denyhosts_restart");

commands:

  "/sbin/service denyhosts restart" -> "Security policy"
     comment    => "Restarting DenyHosts after configuration change or death",
     ifvarclass => canonify("denyhosts_restart");

}

If you’re familiar with cfengine at all, you’ll quickly realize this is not a complete configuration. I am relying on the cfengine standard library for several body definitions as well as custom site variables defined in the common bundle named “g” (not shown). And of course, there are no control bodies, bundlesequence or many other things that make up a complete cfengine configuration, hence “snippet”.

Let’s ignore what’s lacking for now and focus on the meat of the promises.

Packages

The first part of the denyhosts bundle is dealing with packages. I’m making two promises regarding the “denyhosts” package. The first promise is that the package has been added to the system via yum and the second is that the package is up to date via yum. I’m not entirely clear on how to best manage promises like this yet so perhaps I’m missing some cute shorthand for both adding and keeping packages up to date. For now, I’ll stick with two separate promises.

You’ll also notice that I’m only checking to see if the package is installed once a week (via action => if_elapsed) and only checking to see if the package is up to date once every 24 hours (if_elapsed, again). The update promise is also subject to the Night class to ensure that package updates only occur at night and not during the work day. This is just a matter of preference. I’d prefer if updates occur at night, you may not.

Since I’m using a “smart” package manager to ensure that denyhosts is installed, I can count on having yum resolve any dependencies (such as python) for me automatically. I would loath to describe every dependency for every package I want control over by hand.

Files

There is only one file that I’m concerned with when it comes to denyhosts and that is the denyhosts configuration file in /etc/denyhosts.conf. Instead of doing file edits on the default denyhosts.conf file provided in the denyhosts packages that I’ve promised to install, I simply copy a pre-defined configuration from my cfengine server. This file has our site’s default denyhosts configuration all ready to go. If I needed to customize the configuration on a per-host or per-host-type basis, I could copy the base file to a temporary location then perform edits on the temp file and write out the changes to the final location of the default configuration file or simply maintain several pre-configured versions of denyhosts.conf and copy the appropriate file.

Also of note about files is that if the file promise must be repaired (if the file must be copied because it’s changed), I’m setting a class to be defined so that DenyHosts can be restarted. More on that later.

Processes

In this case, I’m only checking to see if the DenyHosts python process is running or not. If DenyHosts is running, we do nothing. If DenyHosts is not running, we define a class using the same name as the class we define if we have to copy the configuration file.

Commands

Finally, in the commands section we tell cfengine how and when to restart DenyHosts. If the “denyhosts_restart” class is defined, we instruct cfengine to restart DenyHosts with the “/sbin/service denyhosts restart” command. The canonify and cdefine special functions in cfengine provide a very powerful way of defining some rather complex relationships.

What is Missing?

Well, probably a lot of stuff. One obvious thing is that I’m not promising that DenyHosts is set to startup at boot time using the hosts’ native init system. Of course, this shouldn’t be a big deal because cfengine will start it up if it’s not running at the next cf-agent run, but perhaps it would be nice to make that promise anyways.

I’m also not using many (or any!) classes to limit the scope of where (to what hosts) these promises will apply. Right now, I’m just working with a test environment so it’s easy to get away with that but I’m learning that it’s good to be as explicit at possible from the start when building promises.

UPDATE: Ah, how could I forget.. Reporting is totally missing! I knew I was setting some of those classes for a reason. In the next installment, I’ll include the most basic of reporting functionality.

I think that’s all for now. Please critique my amateur use of cfengine 3 in the comments, I want to hear from you!

Related posts:

1. Cfengine 3 Snippets Part 2: sudo
2. RHEL/CentOS, NFS and Firewalls
3. Nanorcs: Ultrasimplistic Configuration File Revision Control

Luckily, RedHat’s /etc/sysconfig/nfs configuration file read by  various “nfs”, “nfslock” and RPC services init scripts provides an easy means of locking down specific ports for all the NFS-related services so that one doesn’t have to work around the dynamic port assignment problem when it comes to firewalling.

In /etc/sysconfig/nfs there are six different options relating to port assignment:

1. RQUOTAD_PORT
2. LOCKD_TCPPORT
3. LOCKD_UDPPORT
4. MOUNTD_PORT
5. STATD_PORT
6. STATD_OUTGOING_PORT

These options do not represent all the ports that will be used by the entire NFS service but it includes the most important option for eliminating the uncertainty of rpc.mountd.

I’ve set the port options as follows:

1. RQUOTAD_PORT=875
2. LOCKD_TCPPORT=4045
3. LOCKD_UDPPORT=4045
4. MOUNTD_PORT=861
5. STATD_PORT=865
6. STATD_OUTGOING_PORT=866

After making the changes, restart the “nfs” and “nfslock” services and check to make sure the configured ports are now in fact in use with the “rpcinfo -p” command:

# rpcinfo -p
program vers proto   port  service
100000    4   tcp    111  portmapper
100000    3   tcp    111  portmapper
100000    2   tcp    111  portmapper
100000    4   udp    111  portmapper
100000    3   udp    111  portmapper
100000    2   udp    111  portmapper
100011    1   udp    875  rquotad
100011    2   udp    875  rquotad
100011    1   tcp    875  rquotad
100011    2   tcp    875  rquotad
100021    1   udp   4045  nlockmgr
100021    3   udp   4045  nlockmgr
100021    4   udp   4045  nlockmgr
100021    1   tcp   4045  nlockmgr
100021    3   tcp   4045  nlockmgr
100021    4   tcp   4045  nlockmgr
100003    2   tcp   2049  nfs
100003    3   tcp   2049  nfs
100003    4   tcp   2049  nfs
100003    2   udp   2049  nfs
100003    3   udp   2049  nfs
100003    4   udp   2049  nfs
100005    1   udp    861  mountd
100005    1   tcp    861  mountd
100005    2   udp    861  mountd
100005    2   tcp    861  mountd
100005    3   udp    861  mountd
100005    3   tcp    861  mountd
100024    1   udp    865  status
100024    1   tcp    865  status

Now, the entire NFS-related firewall rules must allow the following ports from the applicable client address range(s):

• Incoming and Outgoing ICMP type 3
• Incoming TCP and UDP ports 111, 861, 865, 875, 2049, 4045
• Outgoing TCP and UDP ports 111, 861, 865, 866, 875, 2049, 4045

These rules can easily be configured with your favorite firewalling software (I’m using fwbuilder to manage iptables rules). Often times firewalls will be configured to allow all outgoing connections, so if that’s the case with your firewalls, don’t worry about specific outgoing rules. I’ve been testing this configuration for two days now and all seems well.

Related posts:

1. Browsing Automounted NFS with Nautilus
2. Cfengine 3 Snippets Part 1: DenyHosts
3. OpenGear CM4116 Review