Redhat Satellite 5: How to Clone Security Errata to a Software Channel

space_dogFirst check to see if the errata is available to your local satellite server. To accomplish this log into your organizations satellite server and click on the “Errata” tab. Then on the left side of the page click on “Advanced Search”.

In the search box enter the RHSA number (Redhat Security Advisory Number) for the errata that you want to clone/update. In this example I am searching for RHSA-2014:1924, which is a Thunderbird security update.

If your search does not return any results, you will need to manually sync your local Satellite Server with Redhat.To accomplish this you need to ssh into your local satellite server and run the command shown below. Note that this does not update any packages/errata. This does update the list of availbile packages/errata.

/usr/bin/satellite-sync
[root@myserver ~]# satellite-sync –email
10:08:09 Red Hat Satellite – live synchronization
10:08:09 url: https://satellite.rhn.redhat.com
10:08:09 debug/output level: 1
….truncated….

Once you are able to locate the specific fix in via “Erratum Search” you may proceed to the next step. In this example, as I stated above, I am searching for RHSA-2014:1924.

clone_erratta

Now that our local Satellite server is aware of our specific errata, click on “Clone Errata” on the left side of the page. Search the page “Errata Management” for the specific fix that you want to apply. Note that the “Errata Management” page does have built in search functionality — don’t ask me why — so you must search using your browser’s own page search function.

clone_thunderbird

Once you have located the correct Security Advisory, put a check in the box and spend about 5 minutes scrolling down to the bottom of the page. Stop when your arm is tired, or once you locate the “Clone Errata” button. Obviously you want to click this.

Note that your newly added and updated errata/package may not become immediatley availible to install. You nay need to run the following commands to refresh/reload your repos.

#yum clean all

Then check for updates with the command below.

#yum check-update

Advertisements

Redhat 6 Minimal Kickstart Configuration with VMware Tools and Puppet Agent Install

smartaHere is my small, crude, little Kickstart configuration and post install script that I have up and running in my lab at home. Don’t expect to find anything too fancy here, as this Kickstart was purposefully built to be small and to the point. Here, the point was to spin up a VM, run through a basic install of CentOS/Redhat Linux, ¬†and install VMware Tools along with a Puppet agent.

Note that this post assumes that you have a working Kickstart server.

First lets take a look at our kickstart file, CentOS-6.6-x86_64-minimal.ks

The section directly below kicks off our kickstart ks file. Here we set our root password (no that’s not my hash) and setup our network interface for DHCP. We do a tiny bit of disk partitioning, and setup very simple LVM. Then we choose our packages. As you can see my package list is not at all fancy, I just want to make sure that I have pretty much every package that might need for a lab VM.

[code language=”bash”]
# Kickstart file for RHEL 6 Minimal
# Small Disk

text
install
url –url=http://10.1.0.106/ks/loop/CentOS-6.6-x86_64-bin-DVD1
lang en_US.UTF-8
keyboard us
network –onboot yes –device eth0 –bootproto dhcp –noipv6
rootpw –iscrypted $6$X/4YYZPN$4Sv.khxXms8N8vRssR/Vl35w/m80FF5P6p7aX0D7EFfD9p734F6tU4kXdcSCoOjPiXLrVxqfKxxxxxxxxxxxq5551
firewall –disabled
authconfig –enableshadow –passalgo=sha512
selinux –permissive
timezone America/New_York

# Disk
bootloader –location=mbr –driveorder=sda –append="crashkernel=auto rhgb"
zerombr
clearpart –all –drives=sda
part pv.1 –grow –size=1
part /boot –fstype=ext4 –size=1024
volgroup VolGroup pv.1
logvol / –fstype=ext4 –name=lv_root –vgname=VolGroup –size=1024 –grow
logvol swap –name=lv_swap –vgname=VolGroup –size=1024

#Network
network –device=eth0 –bootproto=dhcp –nameserver=10.1.0.110

# Package Selection
%packages –nobase –excludedocs
@Base
@core
kernel-headers
wget
perl
sysstat
bind-utils
tcpdump
[/code]

Now let me pause to point out the section below. This is the %pre script that I am using to prompt me for the VM hostname before the install begins. The hostname needs to be set before you install puppet on the VM, otherwise you are going to have to recreate your puppet certificates after you set properly set your hostname post install and reboot.

[code language=”bash”]
%pre –log=/root/ks_pre.log
#change to tty6 to get input
chvt 6
exec </dev/tty6 > /dev/tty6

#Prompt for hostname
echo "What is my hostname?"
read NAME
echo "NETWORKING=yes
HOSTNAME=${NAME}" > network
chvt 1
[/code]

Now we run a simple post install, along with a custom post install script. It is this script that will install Vmware tools and Puppet. Myself, I prefer keeping most of my code out of the actual Kickstart ks file, however you can always jam all your code into it if you like. You will just need to validate your syntax first, as I have not tested my config this way.

[code language=”bash”]
%post –nochroot
# bring in hostname collected from %pre, then source it
cp network /mnt/sysimage/etc/sysconfig/network
. /mnt/sysimage/etc/sysconfig/network
# force hostname change
/mnt/sysimage/bin/hostname $HOSTNAME
#Post Install
%post –log=/root/ks-post.log
cd /root
echo "Getting the post install script – if this takes a long time check network or path"
wget http://10.1.0.106/ks/scripts/centos-6-postinstall.bash
echo "Running the post install script"
/bin/bash centos-6-postinstall.bash
[/code]

Ok, so below is the post install script that I am calling in the section above. After a quick modification of my hosts file, I pull down the Puppet installer from my local Puppet server. Next we install the open source VMware tools packages, after creating the required yum repofile.

 

[code language=”bash”]
#!/bin/bash
#centos-6-postinstall.bash

#Switch to the 6th console and redirect all i/o
exec < /dev/tty6 > /dev/tty6 2> /dev/tty6
chvt 6

# Lets make sure we know who the puppet server is before we get too far
echo "Adding hosts entry for puppet master"
echo "10.1.0.115 puppet puppet.lab.localdomain" >> /etc/hosts

## Update Via Yum – not doing this for now in order to save time
#yum -y update
# Install puppet from local puppet master
echo "Downloading and running Puppet installer"
curl -k https://10.1.0.115:8140/packages/current/install.bash | sudo bash
#Install Open Source VMware Tools
rpm –import http://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-DSA-KEY.pub
rpm –import http://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-RSA-KEY.pub

echo -e "[vmware-tools]\nname=VMware Tools\nbaseurl=http://packages.vmware.com/tools/esx/5.1latest/rhel6/$HOSTTYPE\nenabled=1\ngpgcheck=1" > /etc/yum.repos.d/vmware-tools.repo

echo "Installing Vmware Tools"
yum -y install vmware-tools-esx-nox

#Minor grub.conf modifications
sed -i ‘s/rhgb quiet//’ /boot/grub/grub.conf
sed -i ‘s/hiddenmenu//’ /boot/grub/grub.conf
sed -i ‘s/timeout=5/timeout=10/’ /boot/grub/grub.conf

#Kick off first puppet run, for some reason I think you might need to do this twice.
sleep 5
echo "Running Puppet for the first time"
puppet agent –test
puppet agent –test

#Tell us we have reached the end
echo "We have reached the end of the post-install script"
[/code]

A couple of additional details to note about the post install script above. I like to modify the grub.conf so that I unhide the menu and increase the time out. I also like to make sure that we disable the Redhat graphical boot screen… I want to make sure its easy to catch any errors or miss-configurations in my kickstarts.
 

RHEL6: Cool PAM Tricks – Logging Terminal Keystokes

Pam-original-cooking-spray-72450This is a neat and very useful trick that I learned today. Lets say that you want to be able to monitor and log all keystrokes that are typed as root. This is particularly useful as normally you can only log when a user uses sudo to run a command. If the user has the abilty to become root however,  then they have effectively eluded yourattempts to track their activity. Like Thomas Magnum shaking a tail, they are free to scoot around your island with the top down.

So how do you stop this from occuring? How to you log all activity and keystrokes made by root without implementing a bloated 3rd party software that will probably cost and arm and a leg? You use PAM you dingbat.
 

The secret sauce in this security burrito is the pam_tty_audit.so module. Here is how to use it,

Below is my stock /etc/pam.d/system-auth file

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_fprintd.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

Now look above and then look below at my modified system-auth file. Note the additonal session entry for pam_tty_audit.so.

[root@ip-172-31-21-28 pam.d]# cat system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_fprintd.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_tty_audit.so enable=root
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

Note that you will need to add the pam_tty_audit.so call to your /etc/pam.d/password-auth as well to ensure that you capture all of root's keystrokes, no matter how they log in.

 

Related articles

Much Todo About Linux/RHEL Passwords
RHEL6 – How to Manually Logout of an Iscsi Disk
Fun With PAM: Working with pam_cracklib and pam_tally2

RHEL6: Composing Custom Auditd Rules for Fun and Profit

297247-typewriterAuditd gives you the ability to write your own custom audit rules. This functionality allows an administrator to keep a close eye on system calls, file access, and user behavior. This added functionality is especially useful in environments that are requred to adhear to compliance standards that are above and beyond normal standards. Think PCI.

Once of the simplest rules to add is a watch rule which can be set on files and directories. In the example below we are watching the /etc/passwd file for permission changes (writes and attibute changes specifically). We are creating a custom key to use for organizational purposes.

[root@ip-172-31-21-28 ~]# auditctl -w /etc/passwd -p wa -k edit_watch

Here is a cool one – lets audit all binary executions under /usr/bin.

[root@ip-172-31-21-28 ~]# auditctl -w /usr/bin -p x

Using the -l option you can list your current audit rules, and using the -s option you can see the current status of the auditd subsystem

[root@ip-172-31-21-28 ~]# auditctl -l
LIST_RULES: exit,always watch=/etc/passwd perm=wa key=edit_watch
LIST_RULES: exit,always dir=/usr/bin (0x8) perm=x

[root@ip-172-31-21-28 ~]# auditctl -s
AUDIT_STATUS: enabled=1 flag=1 pid=741 rate_limit=0 backlog_limit=320 lost=0 backlog=0

Want to get down and dirty with audit rules – you can check out the audit rules man page by running the command below.

[root@ip-172-31-21-28 ~]# man audit.rules

 

 

 

Related articles

RHEL6 – SELinux Troubleshooting II: Electric Boogaloo
Linux audit files to see who made changes to a file
A Brief Introduction to auditd

RHEL6: All Up in Your Face with Auditd

Strongbad2kqAuditd is the userland piece of the RHEL audit tool suite. When its up and running, audit messages sent by the kenel will be send to log files that you have configured. By default, only a small and limited number of messages will be picked up by Auditd; these are mostly messages related to authentication and authorization.

Auditd has three main config files as shown below

  • /etc/sysconfig/auditd – basic configuration options
  • /etc/audit/auditd.conf – main config file
  • /etc/audit/audit.rules – auditing rules

Auditd and Syslog:

Its possible to send audit messages to a syslog. By setting active=yes in /etc/audisp/plugins.d/syslog.conf you can send all your audit messages to syslog. If your system is setup to log to a remote syslog server, then your audit messages will go along for the ride as well. Note that you can also send audit messages to a remote logging server via native audit protocol over TCP. I am not going to go into this option, but I want to make sure that we are aware that it exists.

 

Looking for Audit Events in All the Wrong Places:

Auditd includes a handy-dandy tool for searching audit logs. Ausearch. You can check out all your current audit log messages using the command below.

[root@ip-172-31-21-28 ~]# ausearch -l

Viewing audit logs in their raw format can be accomplished with the command below

[root@ip-172-31-21-28 ~]# ausearch –raw

The -a option allows you to search by audit event ids

[root@ip-172-31-21-28 ~]# ausearch -a 282

Auditd also includes ausearch, which allows you to get a quick summary of audit events, rather than trying to view massive audit logs. Usage and output shown below.

root@ip-172-31-21-28 ~]# aureport

Summary Report
======================
Range of time in logs: 07/17/2014 10:21:36.438 – 07/17/2014 19:52:49.556
Selected time for report: 07/17/2014 10:21:36 – 07/17/2014 19:52:49.556
Number of changes in configuration: 4
Number of changes to accounts, groups, or roles: 24
Number of logins: 20
Number of failed logins: 4
Number of authentications: 75
Number of failed authentications: 3
Number of users: 3
Number of terminals: 18
Number of host names: 19
Number of executables: 14
Number of files: 0
Number of AVC's: 10
Number of MAC events: 20
Number of failed syscalls: 10
Number of anomaly events: 0
Number of responses to anomaly events: 0
Number of crypto events: 244
Number of keys: 0
Number of process IDs: 203
Number of events: 1132

You can also use aureport and ausearch together. Simliar to the powerfull partnership between Batman and Robin, these two tools complement each other in ways that you can only imagine. Check out my sexy bits below.

[root@ip-172-31-21-28 ~]# ausearch –start today –raw | aureport

Summary Report
======================
Range of time in logs: 07/17/2014 10:21:36.438 – 07/17/2014 20:01:01.911
Selected time for report: 07/17/2014 10:21:36 – 07/17/2014 20:01:01.911
Number of changes in configuration: 4
Number of changes to accounts, groups, or roles: 24
Number of logins: 20
Number of failed logins: 4
Number of authentications: 75
Number of failed authentications: 3
Number of users: 3
Number of terminals: 18
Number of host names: 19
Number of executables: 14
Number of files: 0
Number of AVC's: 10
Number of MAC events: 20
Number of failed syscalls: 10
Number of anomaly events: 0
Number of responses to anomaly events: 0
Number of crypto events: 244
Number of keys: 0
Number of process IDs: 205
Number of events: 1144

Want to know another cool tool that is part of auditd? I know, its a lot to take in at one time, but I am sure that you can handle it. Using autrace you can trace and investigate system calls made by a process. 

Want to see everything that nslookup is doing? Then run the command below.

[root@ip-172-31-21-28 ~]# autrace /usr/bin/nslookup google.com

This will output a pid for you to trace with ausearch.

Trace complete. You can locate the records with 'ausearch -i -p 3359'

 

Related articles

RHEL6- Getting Up Close and Personal With Rsyslog
Linux audit files to see who made changes to a file

RHEL6: Using Advanced Log File Filtering in Rsyslog

100-8591So by default when you forward logs to a syslog/rsyslog server all the logs end up in the same file (ususally configured to go to the messages file). Sometimes one may prefer to forward logs from a particular server to a separate logfile. I know for a fact that my sometimes friends in our info-sec group prefers this setup.

While managing such a setup for more than a handful of hosts would probably be a nightmare, its not actaually hard to setup on the most basic level.

First create a custom filters.conf (or whatever you want to name it) in your /etc/rsyslog.d directory. Below is the file that I created.

[root@ip-172-31-21-28 rsyslog.d]# cat filters.conf
:fromhost, isequal, "ip-172-31-25-104.ec2.internal" /var/log/ip-172-31-25-104.ec2.internal/messages
:fromhost, isequal, "ip-172-31-25-104.ec2.internal" ~

Note that you will need to include two lines in your file for each host, one with the specific file/location that you want to send your filtered log messages, and a second line that directs rsyslog to discard any messages from the specified hosts once they have been logged to the specified locations. This keeps these messages from ending up in the messages file as well as the file defined in your filter file.

 

Related articles

RHEL6 – Introduction to IPtables, Part II
HomeLab: Basic Syslog Configuration on Cisco Catalyst Devices
RHEL6- Getting Up Close and Personal With Rsyslog

RHEL6: Configuring Encrypted Remote Logging Via Rsyslog

Picresized_1350512420_mummyRsyslog has the ability to forward/recieve encrypted logs using certificates. I am going to go over a very quick and dirty install and configuration. Since I am again sitting in Starbucks and do not have access to my homelab and its abundant resources, I am once again going to use Amazon EC2 instances of RHEL 6.5 for testing. The two instances that I will use we will call Server1 and Server2. Our goal here is not to build out an entire environment, but rather we are just looking to get this working on its most basic level.

Lets start with the log reciever server as we need to install a couple of packages. The first provides the certtool utility and the second provides the tls library for rsyslog.

[root@ip-172-31-21-28 ~]# yum -y install gnutls-utils.x86_64 rsyslog-gnutls

Also note that we are going to be looking at some documentation on the remote hosts to make this install and config a bit easier. You are probably going to want to install lynx so you can view the html documentation files. On my server1 instance, the rsyslog docs are in the following directory – /usr/share/doc/rsyslog-5.8.10.

This is the file that you want to take a look at. Below I am using lynx to view it.

lynx tls_cert_server.html

Now lets head on over to the sending server and install our packages again.

[root@ip-172-31-21-28 ~]# yum -y install gnutls-utils.x86_64 rsyslog-gnutls

Grab these bits from the file and modify to match your system. Then drop it in a file in /etc/rsyslog.d on your rsyslog receiving server.  I am calling my logging.conf

$ModLoad imuxsock # local messages
$ModLoad imtcp # TCP listener

# make gtls driver the default
$DefaultNetstreamDriver gtls

# certificate files
$DefaultNetstreamDriverCAFile /rsyslog/protected/ca.pem
$DefaultNetstreamDriverCertFile /rsyslog/protected/machine-cert.pem
$DefaultNetstreamDriverKeyFile /rsyslog/protected/machine-key.pem

$InputTCPServerStreamDriverAuthMode x509/name
$InputTCPServerStreamDriverPermittedPeer *.example.net
$InputTCPServerStreamDriverMode 1 # run driver in TLS-only mode
$InputTCPServerRun 6514 # start up listener at port 10514

Now, from the same file as you used above, grab the following giggly-bits and stick them out on the rsyslog sending server. Modify the file to match your needs and drop in /etc/rsyslog.d. To keep things simple I am going to call this file logging.conf as well

# certificate files – just CA for a client
$DefaultNetstreamDriverCAFile /path/to/contrib/gnutls/ca.pem
# set up the action
$DefaultNetstreamDriver gtls # use gtls netstream driver
$ActionSendStreamDriverMode 1 # require TLS for the connection
$ActionSendStreamDriverAuthMode anon # server is NOT authenticated
*.* @@(o)server.example.net:10514 # send (all) messages

 

Now, lets review where we are. Our config files are in place on our sending server and our recieving server. Plus we have installed all required packages. Now lets get on to the keys. This is the confusing part, so I will go through my process one step at a time. Once again you can use the built in documentation to help you get this part right.

Jump on the recieving server and check out the file below via lynx

lynx tls_cert_ca.html

Jump into your newly created keys directory.

[root@ip-172-31-21-28 ~]# cd /etc/rsyslog-keys/

And run the command below to generate the private key for your CA (Certficate Authority)

[root@ip-172-31-21-28 rsyslog-keys]# certtool –generate-privkey –outfile ca-key.pem                                        
Generating a 2048 bit RSA private key…

Now we are going to generate a self signed cert from our private key.

[root@ip-172-31-21-28 rsyslog-keys]# certtool –generate-self-signed –load-privkey ca-key.pem –outfile ca.pem

You will be asked a bunch of questions but there are only two important ones that are shown below, make sure you answer yes to both of them.

Does the certificate belong to an authority? (y/N): y
Will the certificate be used to sign other certificates? (y/N): y

Now take this key (ca.pem) and copy it onto the sending server in /etc/rsyslog-keys, or wherever you set your config files to look for them.

Now lets go back to the recieving server so we can genreate a private key.

[root@ip-172-31-21-28 rsyslog-keys]# certtool –generate-privkey –outfile key.pem –bits 2048
Generating a 2048 bit RSA private key…

Now lets generate a request key.

[root@ip-172-31-21-28 rsyslog-keys]# certtool –generate-request –load-privkey key.pem –outfile request.pem

And how lets sign the certificate request and generate a certificate.

certtool –generate-certificate –load-request request.pem –outfile cert.pem –load-ca-certificate ca.pem –load-ca-privkey ca-key.pem

This one also requires you to answer a bunch of questions. These are the two that have "yes" for the answer.

Is this a TLS web client certificate? (y/N): y
Is this also a TLS web server certificate? (y/N): y

Now at this point you should be able to start rsyslog on each server. Using the logger command on your sending server, you should be able to send a message to your local syslog and see it forward to the sender.

 

 

Related articles

RHEL6 – Configuring Apache with TLS/SSL Encryption
RHEL6- Getting Up Close and Personal With Rsyslog
Install and Configure Rsyslog Server in CentOS 6.4 / RHEL 6.4