Not happy with secstate

I finally got a chance to install RedHat 6, but I am having troubles getting secstate started. After some digging, I found a reference to missing puppet configuration files. Looks like I will have to wait for secstate to come out of beta; but I still like the concept of locking down a system and keeping it locked-down.

P.S.> Finally found the examples, but I was hoping for more. At  least an example to would put a system into FDCC/USGCB format. The authors of secstate come from TreSys CLIP project which uses Puppet to maintain a system in a secure state.

Some random thoughts

Still waiting for RedHat 6.0 to be released: The new program secstate looks very interesting. It is being published from Tresys which has a CLIP project in place. This is a version of RedHat which has been locked down based on the CIS benchmark or in this case the new FDCC / USGBC standard. The important thing is the use of puppet in both cases to manage the secure configuration.

I also like how they (Tresys) have mapped some of the CLIP security controls back to FISMA controls; So, with some sort of reporting on the status of the system, it is possible to automate reporting of how the system is doing in terms of FISMA.

EMET from Microsoft

Busy day for Posting: Another thing I have come across is the EMET tool from Microsoft. It basically wraps security around other programs and runs on Windows XP SP3 and later. It does solve the security problems in these programs, but provides protection until a patch can be applied. For example, (not picking on Adobe), but if a malicous pdf is run inside Adobe Reader, EMET will step in and crash Reader to prevent the bad codes from running, thus protecting the system from infection.

So far I have tested it with firefox, Internet Explorer, java and Adobe reader. Also I have wrapped the svchost program which connects the system to the Internet. In addition, I have wrapped lssas which is the local security authentication server. I know the best method is to always know the source of the files you download and scan them with an Antivirus tool; but any extra protection is always welcome.

Ultimate Goal for a Secure system

I have been looking into ways to make my systems the most secure as possible, but making sure my users are able to do their work. One the things I have been following is the use of micro-kernels; this reduces your "Attack Surface" since there is less of the kernel to attack. Also there is a micro-kernel (SEL4) which has been verified by means of Formal Methods to be a very secure kernel. However it is not available for use as a Linux kernel replacement. Its cousin L4 can be used as a Linux kernel replacement very certain functions which I may be looking into.

Another method of securing the system is to look into Trusted Computing. They are generated a trusted system by starting at the boot level. There is code available to verify if the BIOS boot-loader can be trusted. Then the next step is to see if the GRUB or LILO loader can be trusted and finally testing to see if the OS that is loaded can be trusted. Unfortunately there has been problems; Trusted Computing has been advertised as a means to make sure that copyrighted material is not copied and are being controlled by the copyright owner. There has been many cases like Sony and others where the copyright control has gone to far. Another problem is that the chain of trust starts at the BIOS level and it has been shown that a rogue BIOS can be planted on one of the peripheral devices and use to bypass the chain of trust of the main BIOS on the motherboard. These issues might explain why there has not been much work on Trusted Computing since 2008.

Attack Surface

I learned a new term for protecting systems. The Attack surface; so deleting unused services, packages and accounts you reduce the "Attack Surface" of the system and make it more secure. There are tools in development which will be able to test a system a generate a score for the "Attack Surface" of the system. This will not make the systems more secure but provide a means to see which systems need more attention and unfortunately or fortunately provide a metric for management about the current security state of the systems.

Delete unused Service Accounts

Not sure how much of a problem these unused accounts are especially with SElinux watching the show, but to be safe remove them anyway.

/sbin/userdel adm
/sbin/groupdel adm
/sbin/userdel lp
/sbin/groupdel lp
/sbin/userdel shutdown
/sbin/groupdel shutdown
/sbin/userdel halt
/sbin/groupdel halt
/sbin/userdel news
/sbin/groupdel news
/sbin/userdel uucp
/sbin/groupdel uucp
/sbin/userdel operator
/sbin/groupdel operator
/sbin/userdel games
/sbin/groupdel games
/sbin/userdel gopher
/sbin/groupdel gopher
/sbin/userdel ftp
/sbin/groupdel ftp
/sbin/userdel mail
/sbin/groupdel mail
/sbin/userdel xfs
/sbin/groupdel xfs
/sbin/userdel mailnull
/sbin/groupdel mailnull

Vulnerability in OpenSSH CBC Ciphers

I just stumbled upon  this advisory about CBC mode ciphers have a vulnerability.
http://www.openssh.org/txt/cbc.adv

I have looked into this and discovered that some old versions of Putty and WinSCP will need to be updated, but this looks like a good idea to reduce the list of ciphers until a fix is found.

Using Puppet to monitor Monit and Nagios

This completes the triangle with all three services watching each other.

To monitor Nagios with puppet:
# nagios.pp
class nagios {
    service { "nrpe":
        ensure => running,
        enable => true
    }
}

To monitor Monit with puppet:
# monit.pp
class monit {
    service { "monit":
        ensure => running,
        enable => true
    }
}

Include these files in the node class and you will be up and monitoring.

Using Monit to monitor Nagios and Puppet

Moint is the simplest of the bunch to configure; make sure you set daemon "some number of seconds" and it usually runs.

To monitor Nagios (nrpe)
check process nrpe
  with pidfile /var/run/nrpe.pid
  start program = "/etc/init.d/nrpe start"
  stop program = "/etc/init.d/nrpe stop"
  if failed port 5666 then restart
  mode active


To Monitor Puppet"
check process puppetd
  with pidfile /var/run/puppet/puppetd.pid
  start program = "/etc/init.d/puppet start"
  stop program = "/etc/init.d/puppet stop"
  mode active

Next Time I will explain how to get Puppet to monitor Nagios and Monit.

Using Nagios to monitor Puppet and Monit

I am assuming that you have a Nagios server already running and NRPE installed on the systems running Puppet and Monit.

Check to make sure Puppet is running:
checkcommands.cfg:# 'check_puppetd' command definition
checkcommands.cfg:   command_name       check_puppetd
checkcommands.cfg:   command_line       $USER1$/check_procs -c 1:1 -C /usr/sbin/puppetd

Check to make sure Monit is running: (Notice full name to avoid 'monitor' processes)
checkcommands.cfg:# 'check_monit' command definittion
checkcommands.cfg:   command_name       check_monit
checkcommands.cfg:   command_line       $USER1$/check_procs -c 1:1 -C /usr/local/bin/monit

or
in checkcommands.cfg
define command{
  command_name  check_remote_proc
  command_line  $USER1$/check_nrpe -H $HOSTADDRESS$ -t 30 -c check_proc_$ARG1$
}

in services.cfg:
define service{
        use                             prod-tmpl
        host_name                  puppet1
        service_description             puppetd
        check_command                   check_remote_proc!puppetd
}


define service{
        use                             prod-tmpl
        host_name                  puppet1
        service_description             monit
        check_command                   check_remote_proc!monit
}

I am currently working on linking Puppet, Monit and Nagios together

I am using Nagios to monitor critical system services. I get alerts whenever a service stops running or system has gone down. In fact I get notices faster then my users can call to report a problem.

I am using Puppet to enforce system settings and configurations. I inherited a group of servers which were put together by many different System Administrators, so the configuration is different across the different systems. I am in the process of creating a single configuration based on function for each of the systems. The beauty of this is when I need to replace a system with a new one; I can install Puppet and know that everything is set up the way I want it to be. [ Note: RedHat Enterprise Linux version 6 will include a new tool called secstate which will use Puppet to control the system settings.]

I am using Monit to make sure that critical systems are always running. I could use inittab with a respawn but with Monit I get email alerts when there is a change in a service.


To bring this all together, I have Monit watching to make sure that Puppet and Nagios are running. I have Puppet watching Monit and Nagios, and I have Nagios sending out alerts when Monit or Puppet are not running.

I believe that these three complement each other; Nagios is good for monitoring and sending out alerts. Monit is great at making sure that services are always running and Puppet is good at making sure a system stays configured to a defined configuration.

I will try to post some examples of how I each service watching each other and how I wrap a critical system in each package.