security

OpenSCAP Part 3: Running Scans from the Command Line in RHEL 7

/ Christopher Paquin / Leave a comment

openscap-base

Introduction

In part 1 of this series we were introduced to OpenSCAP and the process of running scans via the SCAP workbench. In part 2, we explored concepts and components that define security/vulnerability scans. In this 3rd post we are going to dive into the command line operation.

Let’s get started with oscap.

Installing oscap

In RHEL 7 oscap can be installed with the following command

# yum -y install scap-security-guide openscap-scanner

Content is installed under the following directory. Note that ssg is short for SCAP Security Guide.

/usr/share/xml/scap/ssg/content

Lets change directories to the one listed above and view the installed files.

Screenshot from 2019-07-24 15-58-04

Using oscap we can view more info on each file shown above. In this example we are going to inspect the ssg-rhel7-ds.xml file.

# oscap info ssg-rhel7-ds.xml

Continue reading →

OpenSCAP Part 2: SCAP Content for RHEL 7

/ Christopher Paquin / Leave a comment

openscap-base

Introduction

In part one of the OpenSCAP series we were introduced to the basic usage of the OpenSCAP toolset. In that post we learned how to run a basic scan via the scap-workbench in a desktop environment.

This post will focus on the Content, Profiles, and Targets.

Content

All content will be installed in the directory shown below.  The content in this directory will vary based on the installed OS (the content on my Fedora differs from RHEL for example).

/usr/share/xml/scap/ssg/content

The screenshot below contains a list of content installed by default on RHEL 7.

Screenshot from 2019-07-24 15-58-04.png

Additional content can be obtained and added to the content directory shown above.  For example, NIST content can be downloaded directly from the NIST website. Link below.

National Checklist Program Repository

In the screenshot below we have performed a search for all content that targets RHEL 7.6

Screenshot from 2019-07-25 11-45-44.png

 

Continue reading →

OpenSCAP Part 1: Introduction and Basic Usage for RHEL 7/CentOS 7/Fedora

/ Christopher Paquin / Leave a comment

openscap-base

Introduction

OpenSCAP is a standardized compliance solution for Linux. It is comprised of policies (NIST, STIG, etc) and tooling (oscap, scap-workbench) that allow you to scan and evaluate Linux hosts in order to validate their compliance with industry defined standards.

In addition to providing industry standard compliance rules, OpenSCAP also allows administrators to create custom compliance standards using the scap-workbench.

Administrators can then generate remediation files in bash, ansible or puppet.

Let’s get familiar with OpenSCAP below.

Getting Started

Below is an overview of the “Getting Started” workflow. In this workflow we are gonna run through a very simple use-case, scanning your local Fedora workstation.

  1. Install
  2. Choose Policy
  3. Modify/Adjust
  4. Scan
  5. Remediate

In the sections below we will walk through each of these steps in detail.

Continue reading →

Red Hat OpenStack 8: Making your Undercloud Immutable

/ Christopher Paquin / Leave a comment

chain-and-padlock-macro-wallpaper-background

Introduction

This article will show you how to block the overcloud from being deleted.

Blocking Users from Deleting the Overcloud Stack

First make a backup copy of /etc/heat/policy.json

$sudo cp /etc/heat/policy.json /etc/heat/policy.json.orig

Run the command below to see the default stacks:delete policy.

$ sudo grep -m1 stacks:delete /etc/heat/policy.json
“stacks:delete”: “rule:deny_stack_user”,

Then, make it so that we deny anyone and everyone from removing the stack, even if you’re an admin.

Note, that this means that the policy would have to be reverted back to the original configuration to delete the stack in the future. See sed command below.

$ sudo sed -i /stacks:delete/{s/rule:.*/’rule:deny_everybody”,’/}
/etc/heat/policy.json

Verify your changes.

$ sudo grep -m1 stacks:delete /etc/heat/policy.json
“stacks:delete”: “rule:deny_everybody”,

Blocking Users from Deleting Nova Instances

In addition to blocking users from accidentally deleting your overcloud from heat, you should also block the accidental deletion of the overcloud nodes from nova.

First, run the command below to make a backup of /etc/nova/policy.json.

$ sudo cp /etc/nova/policy.json /etc/nova/policy.json.orig

Run the command below to see the default compute:delete policy.

$ sudo grep compute:delete /etc/nova/policy.json
“compute:delete”: “rule:admin_or_owner”,

Now let’s change the policy so that it blocks anyone and everyone from deleting a compute node.

$ sudo sed -i /compute:delete/{s/rule:.*/’rule:deny_everybody”,’/}
/etc/nova/policy.json

Now we can verify our changes.

$ sudo grep compute:delete /etc/nova/policy.json
“compute:delete”: “rule:deny_everybody”,

RHEL 7 Two-Factor SSH Via Google Authenticator

/ Christopher Paquin / 11 Comments

650x300xgoogle-authenticator-header.png.pagespeed.gp+jp+jw+pj+js+rj+rp+rw+ri+cp+md.ic.194erIegOZ.jpg

In this post,  I am going to walk you through the process of installing and configuring two- factor SSH authentication via Google Authenticator. My base system is running a fresh install of RHEL 7.2

Installation Steps

The first step on my system was to install autoreconf, automake, and libtool. These packages are required by the bootstrap.sh script that we will need to in a couple more steps.

# yum -y install autoconf automake libtool

Now, we are going to install Git.

#yum -y install git

One more dependency to knock out. Install pam-devel as shown below.

# yum -y install pam-devel

Next, we clone the google-authenticator Git repo. In this example, I am cloning to /root

# git clone https://github.com/google/google-authenticator.git
Cloning into ‘google-authenticator’…
remote: Counting objects: 1435, done.
remote: Total 1435 (delta 0), reused 0 (delta 0), pack-reused 1435
Receiving objects: 100% (1435/1435), 2.32 MiB | 0 bytes/s, done.
Resolving deltas: 100% (758/758), done.

Now change directory as shown below and run bootstrap.sh.

# cd /root/google-authenticator/libpam

# ./bootstrap.sh

Now run the following commands to finalize the module installs.

# ./configure

#make

#make install

Assuming that you do not run into any errors, the following modules will be installed.

  • /usr/local/lib/security/pam_google_authenticator.so
  • /usr/local/lib/security/pam_google_authenticator.la

Continue reading →

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

/ Christopher Paquin / Leave a comment

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

RHEL6: All Up in Your Face with Auditd

/ Christopher Paquin

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