Security Monitoring and Enforcement with Cfengine 3
Cfengine has a special cf-agent control variable called suspiciousnames. You can put a list of names into it to warn about during any file search (such as was done during the MD5 hash check). If Cfengine sees these names during recursive (depth) file searches, it will warn about them. If suspiciousnames is not set, cf-agent won't check for them. It's not set by default.
Let me demonstrate how this works by adding the following control block to detect_changes_in_etc.cf:
body agent control
{
suspiciousnames => { ".mo", "lrk3", "rootkit" };
}
A cf-agent control block controls the behavior of cf-agent. This is where you can set things like dry-run mode (don't change anything but report only on what changes would have been made—useful for learning Cfengine), the largest file size Cfengine will edit and so on. So the suspiciousnames variable is set in the agent control block. It's an array of strings.
Let's create a suspiciously named file to see cf-agent get excited:
# date > /etc/rootkit # cf-agent -IKf detect_changes_in_etc.cf Suspicious file rootkit found in /etc #
So, if you're scanning your system directories for an MD5 hash check, you can add the suspicious name check too.
I follow the best practice of securing servers by disabling unnecessary services. I often want to make sure my Web servers are not running CUPS—usually, a Web server does not need to print!
The example shown in Listing 2 is based on the Cfengine unit test unit_process_kill.cf.
Listing 2. cups_not_running.cf
body common control
{
bundlesequence => { "cups_not_running" };
}
########################################
bundle agent cups_not_running {
processes:
"cupsd" signals => { "term", "kill" };
}
The line of interest in Listing 2 is:
processes: "cupsd" signals => { "term", "kill" };
This means if there is an entry in the process table matching “cupsd”, that process will be sent TERM and then KILL signals:
# cf-agent -IKf cups_not_running.cf -> Signalled 'term' (15) to observed process match '28140' -> Signalled 'kill' (9) to observed process match '28140' #
But, let's not be so brutal. Cfengine can report suspicious process names. You can keep an eye out for password sniffers, crackers, IRC bots and so on with the policy shown in Listing 3.
Listing 3. report_suspicious_process_names.cf
body common control
{
bundlesequence =>
{ "report_suspicious_process_names" };
}
###################################################
bundle agent report_suspicious_process_names
{
vars:
"suspicious_process_names" slist =>
{
"sniff",
"eggdrop",
"r00t",
"^\./",
"john",
"crack"
};
processes:
".*"
process_select =>
proc_finder("$(suspicious_process_names)");
}
###################################################
body process_select proc_finder(pattern)
{
command => ".*$(pattern).*";
process_result => "command";
}
The key line here is:
vars: "suspicious_process_names" slist => { "sniff",
"eggdrop", "r00t", "^\./", "john", "crack" };
A variable called “suspicious_process_names” is a list of strings; what we deem as suspicious process names includes, let's say, any processes starting with ./. As you can see, this list can include regular expressions. Cfengine uses Perl-compatible regular expressions.
You can set the contents of this array to reflect what you consider suspicious process names. Then, Cfengine scans the entire process table (that's the processes: .*) and loops over the contents of the “suspicious_process_names” array. Cfengine has implicit looping over arrays, so if you have an array @{suspicious_process_names} and you reference ${suspicious_process_names}, you're actually saying:
for ${suspicious_process_names} in (@{suspicious_process_names}
do
...
done
That's what happens when you say process_select => proc_finder("$(suspicious_process_names)"); You're actually saying, for each element in @(suspicious_process_names), find processes that match that regex.
Anyway, I want this to be a security demonstration rather than a language primer, so let's continue:
# cf-agent -IKf report_suspicious_process_names.cf
!! Matched: root 20044 20002 20044 0.0 0.0
4956 19 664 1 22:05 00:00:00 ./eggdrop
#
The first numeric field (20044) is the PID. The last field is the process name. (Why is there an IRC bot on my Web server?)
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 |
- Designing Electronics with Linux
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Validate an E-Mail Address with PHP, the Right Way
- Tech Tip: Really Simple HTTP Server with Python
- Build a Skype Server for Your Home Phone System
- Why Python?
- A Topic for Discussion - Open Source Feature-Richness?
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?




46 min 20 sec ago
4 hours 48 min ago
8 hours 35 min ago
8 hours 43 min ago
10 hours 58 min ago
13 hours 27 min ago
23 hours 30 min ago
1 day 3 hours ago
1 day 7 hours ago
1 day 8 hours ago