Audit Script to Detect Unix Operating System

In the last few blog entries we have been focusing quite a bit on displaying information from a Unix system via a BASH script. One question that’s come up by quite a few people is, do these commands work on all Unix system? That’s a very valid question.

It turns out that one of my favorite sayings about Unix is that “Unix systems are always the same, they’re just different.” In other words – most Unix flavors share all sorts of similarities. The problem is that there are often very subtle differences between flavors of systems that make it difficult to write one script that will work on all systems. Basically when writing an audit script you have to decide, do you write one script for all flavors and sacrifice on which commands you run to make it consistent, write multiple scripts (one per flavor of Unix), or do you try to do OS detection within your script.

If you decide to do OS detection, I know there are multiple ways to do it. But here is some basic code that we have used in the past in a BASH script to detect which operating system or flavor of Unix is running on a system:

if [ -f /etc/debian_version ]; then
OS="Debian"
VER=$(cat /etc/debian_version)

elif [ -f /etc/redhat-release ]; then
OS="Red Hat"
VER=$(cat /etc/redhat-release)

elif [ -f /etc/SuSE-release ]; then
OS="SuSE"
VER=$(cat /etc/SuSE-release)

else
OS=$(uname -s)
VER=$(uname -r)
fi

echo "Operating System Name: $OS"
echo "Operating System Version: $VER"

Like I said, this likely won’t work on all flavors, you’ll need to test it out on your favorite to make sure it works. In fact if you have suggestions to improve it, please submit them to [email protected] and we’d be happy to update ours too. Happy scripting!

Unix Audit Script for Disk Utilization

We’ve noticed an issue on some of our Unix servers lately. This may not be completely security related (unless of course we’re talking about the availability of a system). We have noticed on quite a few occurrences lately that the disk space on our Unix servers has started to grow out of control to the point where the availability of the system was at risk. Sometimes this happens because of log files that grow too large, databases grow larger than expected, or backups don’t rotate like we planned. But in any case the result is the same – disk drives start filling up to the point where there isn’t much disk space left.

So a while ago we implemented a few BASH scripts to check for free disk space and then report that disk utilization to the help desk on a regular, automated basis. Using the following simple Unix shell commands, we started reporting on the disk utilization for each of our systems.

Information on the installed physical disks on a system:

fdisk -l | head -2 | grep Disk

Information on the installed physical partitions on a system:

fdisk -l | tail -8 | awk '/dev/ { print $1 " " $5 " " $7 }'

Information on the available free disk space on a system:

df -h | awk '{if ($1 != "Filesystem" && $1 != "none") print $1 " " $5}'

Now, if you want to automated these scripts, I would recommend using the Cron or Anacron services to run these commands on a daily or weekly basis. For the reporting side, I really like the tool “SendEmail” for Unix and Windows systems to generate the email. But certainly that’s just a matter of preference.

You might also consider adding these commands to your Unix baseline script. That way during a baseline activity or during an audit you can gather info on disk utilization as well.

More Unix Audit Script One Liners

In our last post we gave some examples of Unix audit script one liners for baselining information from a Unix system. It turns out there are more people than we thought who are interested in this topic and are looking to include commands like these in their scripts. We definitely appreciate everyone’s enthusiasm and decided to post more commands in an effort to help you with your scripts.

So here are a few more Unix audit script one liners for you to try. Enjoy!

List the available IPv4 Address(es) from a system:

ifconfig -a | awk '/inet addr:/ { print $2 }' | cut -d: -f2

List the available IPv6 Address(es) from a system:

ifconfig -a | awk '/inet6 addr:/ { print $3 }'

List the available MAC Address(es) from a system:

ifconfig -a | awk '/Ether/ { print $5 }'

Find all SUID files on a Unix system:

find  / -ignore_readdir_race -perm 04000

Find all GUID files on a Unix system:

find  / -ignore_readdir_race -perm 02000

Find all Sticky files on a Unix system:

find  / -ignore_readdir_race -perm 01000

Again, we would strongly recommend scheduling your scripts and creating automated alerts via email alert functions and your help desk software. It will help keep you honest and track your progress.

Another fun idea that one of our clients suggested was to create your script and then execute it at the conclusion of every vulnerability scan that you run. It turns out most vulnerability scanners give you the ability to execute a script at the conclusion of your scan, your audit script could be what you execute. If you really want to get fancy, you could even centralize your output files via SSH to a central server so you, auditors, or sysadmins could review the results at will.

Unix Audit Script One Liners

Lately I’ve had quite a few requests come in from students and clients to review the audit script that companies are using to audit their Unix / Linux systems. It seems like every company has one person who, at some point in time, wrote a script to audit Unix systems, or they downloaded one from someone online. But in either case people keep wondering – exactly what information are they gathering, and is it the right information to help in an audit?

I know there are multiple languages a company could use to write their Unix audit script, but for me BASH (Bourne Again Shell) scripting has always been the way to go. I don’t have any problem with a company using Perl or Python for their scripts. My only concern is that there have been quite a few times that during an audit an interpreter for either language might not be on the system I’m auditing. And due to principle, I just don’t feel right asking a sysadmin to install an interpreter – not that they would even if I asked!

All that being said, I figured I would write up some Unix audit one liners to inspire you to write your own scripts. If you are writing your own, here are a few to get you started:

Display the name of the system:

Unix Host Name: $(hostname -s)

Display the DNS name of the system:

DNS Domain Name: $(hostname -d)

Display the CPU installed in the sytem:

CPU Model Name: $(cat /proc/cpuinfo | awk -F": " '/model name/{CPU=$2} END{print CPU}')

Display the CPU speed of the installed CPU:

CPU Speed (MHz): $(cat /proc/cpuinfo | awk '/cpu MHz/ { print $4 }')

Display the installed physical memory:

Total Physical Memory (MB): $(free -m | awk '/Mem:/ { print $2 }')

Display the memory in use on the system:

Used Physical Memory (MB): $(free -m | awk '/Mem:/ { print $3 }')

Display the available memory on the system:

Available Physical Memory (MB): $(free -m | awk '/Mem:/ { print $4 }')

We will post more one liners later this month. Hopefully this inspires you to take a look at the script you use or maybe even start writing your own.

Parsing Lynis Audit Reports

Last week we passed along some information on a Unix audit tool called Lynis, maintained by Michael Boelen (https://cisofy.com/lynis/). The value of this tool is that it is an open script that auditors can give to system administrators to run on their Unix servers in order to assess specific technical security controls on the system.

If an auditor chose to use this tool to gather data, likely the process would look something like this:

  1. The auditor gives a copy of the script to the data custodian (system administrator).
  2. The system administrator runs the script on the target machine (note, it does not work across the network).
  3. Lynis produces an output file: /var/log/lynis-report.dat (location can be customized).
  4. The system administrator gives the auditor a copy of this output file.
  5. The auditor parses the file for relevant information to include in their findings report.

Unfortunately the output report isn’t quite as pretty as you might hope. The auditor will need to plan on spending some time parsing the outputs of the report file in order to gather useful information that can be included in their audit report. The data can most certainly be copy and pasted and manually edited, but why not use a little command line scripting to make our lives easier.

At a minimum, an auditor will want to parse a list of all the warnings and suggestions automatically made by the tool. Let’s use built in commands, like the Linux cat, grep, and sed commands. A simple command line command that will give an auditor the ability to parse out only the warnings made in the report file is the following:

cat /var/log/lynis-report.dat | grep warning | sed –e ‘s/warning\[\]\=//g’

The same can be done with the suggestions as well using the following command line syntax:

cat /var/log/lynis-report.dat | grep suggestion | sed –e ‘s/suggestion\[\]\=//g’

A couple other commands that you might want to play with to parse this file are the following commands as well. The following gathers a list of all installed software packages on the system:

cat /var/log/lynis-report.dat | grep installed_package | sed –e ‘s/installed_package\[\]\=//g’

The following command gathers a list of all the installed shells on the system from the report:

cat /var/log/lynis-report.dat | grep available_shell | sed –e ‘s/available_shell\[\]\=//g’

You get the idea. The system administrator can provide the auditor one output file, and the auditor could easily write a parsing script based on this syntax to completely parse the file into a manageable output that is a little more friendly to read.

We hope this inspires you to continue writing your own scripts to automate the audit process. The more we can automate, the faster our audit analysis. The faster our audit analysis, the more technical audits we can perform and the more likely our systems will be properly secured. Until next time…

Unix Auditing with Lynis

One of the questions I get asked often times in our audit classes is how to automate data collection from systems in a way that system administrators will trust. The problem is that there are a number of tools available for doing data collection, but often times those tools are compiled with no easy way to do code review on the tool. And rightfully so, sysadmins are normally cautious about installing software on their systems that they’ve not had the time to verify.

One solution to this is to write your own scripts for automated data collection. We tend to recommend keeping things simple with languages like PowerShell and Bash. One of the nice things about using these languages is that it allows the sysadmin the ability to do code review prior to running the tools. This can give them a little more comfort with the tools typically. But we don’t always have the time to write our own. So what then?

One option, at least for Unix, is to run a tool called Lynis (https://cisofy.com/lynis/). Michael Boelen is lead developer on this project, and from the site he says that:

“Lynis is an auditing tool for Unix (specialists). It scans the system and available software, to detect security issues. Beside security related information it will also scan for general system information, installed packages and configuration mistakes.

This software aims in assisting automated auditing, software patch management, vulnerability and malware scanning of Unix based systems. It can be run without prior installation, so inclusion on read only storage is no problem (USB stick, cd/dvd).

Lynis assists auditors in performing Basel II, GLBA, HIPAA, PCI DSS and SOX (Sarbanes-Oxley) compliance audits.

Intended audience:
Security specialists, penetration testers, system auditors, system/network managers.

Examples of audit tests:
– Available authentication methods
– Expired SSL certificates
– Outdated software
– User accounts without password
– Incorrect file permissions
– Firewall auditing”

In addition it has been found to run on the following Unix operating system platforms:

Arch Linux; CentOS; Debian; Fedora Core 4 and higher; FreeBSD; Gentoo; Knoppix; Mac OS X; Mandriva 2007; OpenBSD 4.x; OpenSolaris; OpenSuSE; PcBSD; PCLinuxOS; Red Hat, RHEL 5.x; Slackware 12.1; Solaris 10; Ubuntu

The nice thing about this tool is that even for junior Unix auditors, or senior auditors without a lot of experience on Unix systems, it is simple to gather information and potential findings on a system. Like similar tools on Microsoft Windows (think MBSA), Lynis gives auditors the ability to identify findings on a system simply by running the tool. There is no install necessary, simply unzip the tools and run the script.

The tool is free and the code is easy enough to review if you enjoy that kind of thing. Hopefully you will find that this becomes a staple of your audit toolkit. Enjoy!