Security Monitoring and Enforcement with Cfengine 3
Case Study
In 2000, David Ressman and John Valdes of University of Chicago reported in a LISA paper “Use of Cfengine for Automated, Multi-Platform Software and Patch Distribution” how they detected a cracker using similar functionality in Cfengine 2:
Since the people who break into our systems almost exclusively use the compromised systems to run sniffers, IRC bots, or DoS tools, we decided to make up a list of suspicious process names to have Cfengine look for and warn us about every time it ran. Besides the usual suspects (more than one running copy of inetd, anything with “sniff”, “r00t”, “eggdrop”, etc., in the process name, password crackers, etc.), we had Cfengine watch for any process with “./” in the process name.
One afternoon, we got an e-mail from Cfengine on one of our computers that had noticed that the regular user of that machine was running a program as “./irc”. It wasn't uncommon to see our users using “./” to run programs, nor do we have objections to our users running IRC, but in this case, it was a bit unusual for this particular user to be running an irc process (good UNIX system administration practice also dictates that you know your users).
Poking around the system, we discovered that the person running this program was not the regular user of the machine, but was someone who had evidently sniffed our user's password from somewhere else and remotely logged in to his system just minutes before Cfengine had alerted us. This person was in the process of setting up an IRC bot and had not yet tried to get a root shell.
You can add to your defense-in-depth by monitoring for suspicious process names.
You can increase your security situational awareness by knowing on what ports your server is listening. Intruders may install an FTP server to host warez or install an IRC server for bot command and control. Either way, your server's TCP profile has changed (increased) in terms of on what TCP ports it listens.
By constantly comparing desired and actual open TCP ports, Cfengine quickly can detect an intrusion. Cfengine 3 runs every five minutes by default, so it can detect a compromise pretty fast.
The code example shown in Listing 4 starts with hard-coded lists of what TCP ports and corresponding process names are expected on the system: 22 sshd 80 httpd 443 httpd 5308 cf-server. It then uses lsof to get the actual list of TCP ports and process names, compare them and report DANGER if the comparison fails.
Listing 4. check_listening_ports.cf
body common control
{
bundlesequence => { "check_listening_ports" };
inputs => { "Cfengine_stdlib.cf" };
}
bundle agent check_listening_ports
{
vars:
"listening_ports_and_processes_ideal_scene"
string =>
"22 sshd 80 httpd 443 httpd 5308 cf-server";
# this is our expected configuration
vars:
"listening_ports_and_processes" string =>
execresult("/usr/sbin/lsof -i -n -P | \
/bin/grep LISTEN | \
/bin/sed -e 's#*:##' | \
/bin/grep -v 127.0.0.1 | \
/bin/grep -v ::1 | \
/bin/awk '{print $8,$1}' | \
/bin/sort | \
/usr/bin/uniq | \
/bin/sort -n | \
/usr/bin/xargs echo", "useshell"); # actual config.
# tell Cfengine to use a shell with "useshell"
# to do a command pipeline.
classes:
"reality_does_not_match_ideal_scene" not =>
regcmp (
"$(listening_ports_and_processes)",
"$(listening_ports_and_processes_ideal_scene)"
); # check whether expected config matches actual
reports:
reality_does_not_match_ideal_scene::
"
DANGER!
DANGER! Expected open ports and processes:
DANGER! $(listening_ports_and_processes_ideal_scene)
DANGER!
DANGER! Actual open ports and processes:
DANGER! $(listening_ports_and_processes)
DANGER!
"; # and yell loudly if it does not match.
# Note: A "commands" promise could be used in
# addition to "reports" to send a text message
# to a sysadmin cell phone or to feed
# CRITICAL status to a monitoring system.
}
Here's an example run:
# cf-agent -IKf ./check_listening_ports.cf R: DANGER! DANGER! Expected open ports and processes: DANGER! 22 sshd 80 httpd 443 httpd 5308 cf-server DANGER! DANGER! Actual open ports and processes: DANGER! 22 sshd 80 httpd 443 httpd 3306 mysqld 5308 cf-server DANGER!!! #
Again, this is a security demonstration, not a language primer, but if you want to understand the policy, follow the Quick Start Guide for Cfengine. If you need any help understanding this policy, come to the help-cfengine mailing list or ask me directly at aleksey@verticalsysadmin.com.
Aleksey Tsalolikhin has been a UNIX/Linux system administrator for 14 years.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Web & UI Developer (JavaScript & j Query)
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




4 hours 4 min ago
14 hours 44 min ago
20 hours 30 min ago
20 hours 48 min ago
22 hours 41 min ago
1 day 34 min ago
1 day 7 hours ago
1 day 7 hours ago
1 day 9 hours ago
1 day 15 hours ago