Press "Enter" to skip to content

Category: Linux

DISA Approves STIGs for VMware NSX on DoD Networks

NSX STIG Photo credit: @_stump

There a lot of abbreviations in this title so I will give a very brief rundown on what it all means and why some of you should care.

In the public sector, our systems are hardened (locked down) a bit more drastically than your traditional private company might do things. Simply deploying a fresh copy of Windows from ISO is prohibited unless strictly spelled out in your lab environment. The governing body who regulates these mandatory compliance settings is known as the Defense Information Systems Agency, or DISA for short. They work closely with the product teams to ensure that when said product is deployed onto a network, it is as secure as possible while still maintaining functionality. These guides are known as STIGs or security technical implementation guides.

With DISA approving the NSX STIGs, VMware’s NSX becomes the first software-defined network solution to do so.

Now, as anyone who has deployed STIGs knows, sometimes the settings within them have a tendency to break previous functionality. With that said, take your time, test everything as you implement, and don’t be afraid to take note of any exemptions your project may need to adjust. Work closely with your ISSO’s and document everything up front as it will save you pain as you go along.

Here are links to the direct zip’s for the STIGs above:

VMware NSX STIG Overview, Version 1
VMware NSX Manager STIG, Version 1
VMware NSX Distributed Firewall STIG, Version 1
VMware NSX Distributed Logical Router STIG, Version 1

Comments closed

Shellshock CVE-2014-6271 Vulnerability and Ansible Playbook


It’s been an interesting year in terms of finding massively exploitable Linux issues. Heartbleed was a nightmare that caused several late and long nights for IT teams across the entire globe. It was also one of the first times the Windows IIS crew could sit back and laugh at us for once. And now here we are with a second vulnerability with an even bigger footprint than Heartbleed.

Early Wednesday morning, NIST released information about a 10/10 severity vulnerability and thus began the latest scramble to check and patch. This issue can be exploited on basically every *Nix box running Bash and every machine running Mac OS X, which suffice to say, is a LOT.

TL;DR version of this exploit is that is acts a code injection via function calls that continue to run after being defined.

The check:
Fire up terminal and paste in:

If it displays ‘busted,’ you are open for attack.

The fix:
I run an EL6 environment and upon waking up this morning found that Red Hat and CentOS both have patched versions of Bash available via yum. You can simply ‘yum update -y bash’ from your EL6 boxes and call it a day. If you have a lot of boxes and employ Ansible in your environment, here is a quick Playbook to massively roll this out. Obviously you can use whatever flavor of automation you like, I just dig Ansible at the moment.

If you want some more information on the matter, here are some fun links:
CVE-2014-6271: remote code execution through bash
Everything you need to know about the Shellshock Bash bug
Resolution for Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271) in Red Hat Enterprise Linux

Comments closed

Centralized rsyslog with ESXi 5.x hosts

One of the most important things in any environment is the syslog server. A centralized host to keep all the debug, runtime, and access information to be sent to your Kibana/Logstash or Splunk implementations will make any sysadmins life easier. The walk-through below sets up a central server running rsyslog, accepting logs on 514 from TCP and UDP, as well as placing them in dated folders for easier organization. Let’s dive in:

Create a dump folder for your syslog structure:

Edit /etc/rsyslog.conf and remove the comments for TCP and UDP reception as well as change receiving port to your liking:

Create a conf file within /etc/rsyslog.d (e.g. daily_log.conf) and define the daily rotation:

Recycle the rsyslog service:

That covers the syslog server side of things, now to get rid of that annoying ‘system logs are not on persistent storage’ warning.

You can add this info to a host profile and apply it against all your hosts if your environment is large, but for example purposes, this will be a one-off host. You can also easily set this up via pCLI script.

Display your current settings:

Adjust syslog settings:

Recycle ESXi syslog service:

Open up syslog ports on ESXi firewall:

And that’s it! Now on your syslogd server, you should see a directory path similar to /var/log/syslogd/year/month/day/hosts*.log

From here on out, you can point all of your log analyzers to the centralized syslog server and keep an eye on your ESXi hosts. Cheers!

Comments closed