IT Dribble

CentOS 7 and Redhat 7 seem to love shoving logs into /var/log/messages and if you run ansible in-house then it generates a lot of noise and if you run Splunk or ELK then getting your logs ‘just right’ is important to O.C.D type levels!

To send your ansible generated logs to /var/log/ansible.log perform the following:

Create the file /etc/rsyslog.d/ansible.conf

if ( $programname contains "ansible" ) then /var/log/ansible.log
& stop

and if you are creating log files you will want to manage those log files too!
Create the file /etc/logrotate.d/ansible

/var/log/ansible.log {
        notifempty
        weekly
        rotate 4
        missingok
        compress
    }

And restart / reload rsyslog

service rsyslog restart

Determine which profile you want to use: oscap info /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml replacing the –profile line as required.

Perform a scan:

  oscap xccdf eval --report report.html 
      --profile xccdf_org.ssgproject.content_profile_CS2 
       /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml 

Apply a remediation:

  oscap xccdf eval --remediate --report report.html 
      --profile xccdf_org.ssgproject.content_profile_CS2 
       /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml 

I’m always forgetting how to debug a python script within Splunk.
Use the following command to initialise the Splunk variables etc and debug your script:

$SPLUNK_HOME/bin/splunk cmd python /full/path/to/yourscript.py

Once upon a time Splunk had an “EventType” named “Key_Events_On_Hosts” then one day it disappeared. It used to power some reports that I use. So I had to go find it from a backup. Here is the EventType is all it’s naked glory.

( sourcetype="WinEventLog*" OR sourcetype="XmlWinEventLog*" (Type="*Error*" OR Type="*Fail*" OR EventCode=1074 OR EventCode=19 OR EventCode=20 OR EventCode=21 OR Eventcode=1001) ) OR ( 
sourcetype="WindowsUpdateLog" (status="installed" OR status="failure" OR status="restart required") ) 

I was lucky enough to spend the morning trying to get mod_auth_kerb working with our existing installation of Centrify without creating any additional SPNs.

It was actually very straight forward except for the missing component of the secret sauce, that’s not documented in many places.
Basically to get it to work perform the following on RedHat 6 (and CentOS 6):

yum install httpd
yum install mod_auth_kerb

vim /etc/httpd/conf.d/auth_kerb.conf

#
# The mod_auth_kerb module implements Kerberos authentication over
# HTTP, following the "Negotiate" protocol.
#

LoadModule auth_kerb_module modules/mod_auth_kerb.so

#
# Sample configuration: Kerberos authentication must only be
# used over SSL to prevent replay attacks.  The keytab file
# configured must be readable only by the "apache" user, and
# must contain service keys for "HTTP/www.example.com", where
# "www.example.com" is the FQDN of this server.
#

<Location /private>
  SSLRequireSSL
  AuthType Kerberos
  AuthName "Kerberos Login"
  KrbMethodNegotiate On
  KrbMethodK5Passwd On
  KrbAuthRealms YOURDOMAIN.COM
  Krb5KeyTab /etc/krb5.keytab
# KrbServiceName is the Centrify secret sauce
  KrbServiceName http
  require valid-user
</Location>

chown root:apache /etc/krb5.keytab
chmod 640 /etc/krb5.keytab

And that’s it. Hopefully “KrbServiceName http” was the secret sauce you needed!