{"id":675,"date":"2014-03-19T14:26:39","date_gmt":"2014-03-19T19:26:39","guid":{"rendered":"https:\/\/www.softwareab.net\/wordpress\/?p=675"},"modified":"2014-06-04T10:57:31","modified_gmt":"2014-06-04T15:57:31","slug":"auto-harden-esxi-5-x-hosts","status":"publish","type":"post","link":"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/","title":{"rendered":"Auto-Harden ESXi 5.x Hosts"},"content":{"rendered":"<p>To run an ESXi 5.x host in a secure network requires the system to be compliant to all Information Assurance (IA) requirements. This article describes in detail how an automated hardening process was created to meet <a href=\"http:\/\/www.disa.mil\/\">Defense Information Systems Agency (DISA)<\/a> requirements based on the latest <a href=\"http:\/\/iase.disa.mil\/stigs\/\">Security Technical Implementation Guide<\/a> for ESXi.<\/p>\n<p><!--more--><\/p>\n<h3>ESXi 5.x Auto-STIG Scripts &#8211; Here&#8217;s the Link!<\/h3>\n<p>The below discusses the auto-hardening process in great, excruciating detail. As an extra, you can<br \/>\n<a href=\"\/wordpress\/wp-content\/uploads\/2014\/03\/20140604_STIG_Scripts.zip\">download the 06-JUN-2014 version of the Auto-STIG Scripts here<\/a>. <strong>This version includes the fix for ESXi 5.0 to the <code>bad substitution<\/code> reported for line 202 as well as a few other errors.<\/strong> Enjoy \ud83d\ude42<\/p>\n<p><strong>Update as of 06 JUN 14: <\/strong> The script function <code>esxi_stig_auto_persist<\/code> referenced below has been updated into the ZIP file along with the required <code>esxi_stig_is_ESXi_5_0<\/code> script.<\/p>\n<h3>ESXi 5.x Auto-STIG Scripts &#8211; What\u2019s the Deal?<\/h3>\n<p>Within DoD and the Army, only properly secured systems can be attached to functioning networks. This article discusses what these requirements are (brief overview) and then how we addressed this need for ESXi 5.x hosts.<\/p>\n<h4>Hardening ESXi Hosts &#8211; Overview<\/h4>\n<p>This section briefly discusses what the requirements are to attach a system to a military network:<\/p>\n<ul>\n<li><strong>A &#8220;STIG&#8221; exists for the server function.<\/strong> The DoD Information Systems Agency (DISA) provides a whole set of Security Technical Implementation Guides (STIGs) that define checklist items to make an installed system or application secure. These are located at http:\/\/iase.disa.mil\/stigs\/. For this article, we are looking at the ESX STIGs (http:\/\/iase.disa.mil\/stigs\/os\/virtualization\/esx.html); specifically, the ESXi 5 Server STIG (Version 1, Release 4) updated on 24-JAN-2014.\n<p>An example of a STIG checklist item is:<\/p>\n<pre><code>Rule Version (STIG-ID): SRG-OS-000126-ESXI5\r\nRule Title: The system must set a timeout for the ESXi Shell to automatically disable idle sessions after a predetermined period.\r\n\r\nVulnerability Discussion:  If ESXi Shell is enabled on the host and a user forgets to logout of their SSH session the idle connection will remain indefinitely increasing the potential for someone to gain privileged access to the host.<\/code><\/pre>\n<p>The STIG checklist will have typically dozens (or even hundreds) of items like this. Each checklist item must be addressed in a way that can be proved to the Information Assurance Manager (IAM). And &#8211; that proof is the point of this article \ud83d\ude42<\/li>\n<li><strong>Servers are built from approved images.<\/strong> As an example, Windows Server 2008 R2 is an approved operating system but the DoD has its own pre-hardened &#8220;Unified Golden Master&#8221; (UGM) which system administrators are to use when bilding new Windows Server operating systems. As of this writing (14 MAR 2014) Windows Server 2012 has no UGM and is not officially supported for installation in secured environments. For other images (such as ESXi 5.x) there is no official UGM but instead the system administrators must use the latest vendor-supplied version and then harden the system.<\/li>\n<li><strong>Patches are applied.<\/strong> Prior to any other hardening, the system administrator first locates and downloads any necessary vendor-supplied security patches. For a network device like a switch, this will probably be a firmware update. For an operating system like Windows Server, this will be the set of Windows Updates that apply to that system (applied from a local DVD, as of course an insecure system will *not* be connected to the Internet). For ESXi 5.x, these patches are the set of updates downloaded and applied to that hypervisor.<\/li>\n<li><strong>STIG(s) are applied.<\/strong> The number of STIG checklist items to apply to an information system vary. For a Windows Server built from the UGM, the base operating system is already highly secured (around 92% pass rate based on our observations). However, if an application (like IIS) is installed on top of the base UGM image, that application must be properly secured using the appropriate STIG. For a system like ESXi 5.x which has no UGM, the system administrator must apply STIG checklist items manually.<\/li>\n<li><strong>Scans are performed.<\/strong> Depending on the system \/ device, different scanning tools may be available. For most operating systems, DISA provides the Security Content Automation Protocol (SCAP) tool at http:\/\/iase.disa.mil\/stigs\/scap\/. The system administrator can run this tool and get an idea of how compliant the system under review is to the relevant STIG checklists (which are XCCDF files and can be processed electronically. Additionally, most systems can be scanned by the Retina tool to determine compliance to known Information Assurance Vulnerability Alerts (IAVAs).<\/li>\n<li><strong>POA&#038;Ms are Defined.<\/strong> &#8220;POA&#038;M&#8221; (pronounced &#8220;POE-am&#8221;) stands for Plan of Actions &#038; Milestones. This accounts for STIG checklist items that can\u2019t be addressed; for example, ESXi 5.x STIG checklist item <code>ESXI5-VMNET-000001<\/code> which applies to distributed virtual switches where the initial environment uses only standard virtual switches. In that case, the POA&#038;M may specify that as the ESXi host is attached to a functional vCenter Server environment, that distributed virtual switches will be applied only according to policy (with verifiable proof and a timeline). The POA&#038;M can also be used to address known deficiencies; for example, a security patch might be known to break a running system (some Windows IIS patches are infamous for doing this). The POA&#038;M would specify which security patches cannot be applied, the rationale, the expected timeline until the patch *can* be applied, and any security mitigations that can be performed to reduce the risk to the running information system.<\/li>\n<li><strong>The system is accredited.<\/strong> This process is part of the overall DoD Information Assurance Certification &#038; Accreditation Program (DIACAP). It basically means that an individual with proper authority (the Designated Approval Authority, or DAA) has reviewed the information system, the security artifacts (such as STIG checklist items and Retina scans), the POA&#038;Ms (if any), and has accepted the risk to run the information system.<\/li>\n<li><strong>Operations &#038; Maintenance Commence.<\/strong> Once the information system is operational, it must be maintained. Security patches must be applied to meet suspense dates (normally 10 days or less from the release of a security bulletin), continuous security scans must be performed, logs must be reviewed and correlated to detect intrusion or subversion, and a plan must be executed to maintain the information system through the entire lifecycle. The entire accreditation process must be repeated at least every 3 years.<\/li>\n<\/ul>\n<p>That\u2019s a lot of steps! We won\u2019t cover any but Step 4 above regarding applying STIG checklist to ESXi 5.x hosts. Our goal will be to have a highly-secure ESXi host with minimal manual effort.<\/p>\n<h4>Hardening ESXi Hosts &#8211; Why Do This?<\/h4>\n<p>One question is <em>why<\/em> do we have this article? Given that we know we need to harden the ESXi hosts using the DISA STIG checklist, why not just do that? After all, the STIG checklist items always fall into one of two categories: <em>policy decisions<\/em> such as <code>ESXI5-VMNET-000001<\/code> (&#8220;All dvPortgroup VLAN IDs must be fully documented.&#8221;); and, <em>implementation actions<\/em> such as <code>ESXI5-VMNET-000010<\/code> (&#8220;All port groups must be configured to a value other than that of the native VLAN.&#8221;). For policy decisions, there is no direct action; the system administrator must be able to prove that a written policy exists and that a process is wrapped around enforcing that policy. For the <code>ESXI5-VMNET-000001<\/code> checklist item, this can be as simple as a one-paragraph written statement that says &#8220;We will fully document all dvPortgroup VLAN ID usage&#8221; along with a brief set of steps on <em>how<\/em> that policy will be implemented (e.g. set up a spreadsheet, document VLAN IDs within the spreadsheet, store the spreadsheet in protected version control, and have a defined change management process to make sure the spreadsheet can\u2019t be modified without permission).<\/p>\n<p>For implementation actions, however, there are some steps that can be performed. Using <code>ESXI5-VMNET-000010<\/code> as an example, the STIG checklist text has some actions that can be performed to verify whether or not the ESXi host is compliant (e.g. run &#8220;<code>esxcli network vswitch standard portgroup list<\/code> and look for usage of VLAN 1). If the check fails, then this is a finding and the system administrator must correct the problem immediately or show that a POA&#038;M exists. And it is these <em>detectable<\/em> checklist items that we want to automate. In many cases, we can fix the problem automatically; consider the checklist item <code>GEN000790-ESXI5-000085<\/code> &#8220;The system must prevent the use of dictionary words for passwords.&#8221; To fix this security violation, you simply modify the <code>\/etc\/pam.d\/passwd<\/code> file and make a single line change..hey, presto! No more security violation!<\/p>\n<p>And that sums up why we want to have ESXi 5.x hardening scripts to make these simple changes (like <code>GEN000790-ESXI5-000085<\/code>) as well as to detect security violations (like <code>ESXI5-VMNET-000010<\/code>) right up front to make it easier to get the ESXi host ready to attach to a connected network.<\/p>\n<h4>Hardening ESXi Hosts &#8211; Doesn\u2019t Anyone Else Have This?<\/h4>\n<p>So now that we know what the hardening process is and why we want scripts to automate the process, a fair question is why we should write anything ourselves.<br \/>\nThere are options for applying DISA STIG checklists to different systems. For example, Aqueduct project at https:\/\/fedorahosted.org\/aqueduct\/ has all sorts of hardening scripts for Red Hat Enterprise Linux (RHEL); basically, you download the script(s) and run them and &#8211; voila! &#8211; you have a hardened RHEL. For ESXi, not so much the case. For example, a 13-OCT-2013 question to a Google Group (https:\/\/groups.google.com\/forum\/#!msg\/pysphere\/a7q_9tnyR5E\/TQt1cWFER-gJ) asks the simple question <em>&#8220;Not sure why the government has security requirements and doesn&#8217;t provide a script to apply the settings.&#8221;<\/em> While the Google Group discussion does provide a Python script download, this is for the Virtual Machine (VM) STIG &#8211; not for the ESXi host STIG. So it isn\u2019t an option for us.<br \/>\nVMware\u2019s own William Lam provides a vSphere Security Hardening report script at https:\/\/github.com\/lamw\/vghetto-scripts\/blob\/master\/perl\/vmwarevSphereSecurityHardeningReportCheck.pl. While this is a great tool and start, it is not really DISA STIG specific.<br \/>\nThe net result? We are stuck developing our own STIG checklist automation script. So let\u2019s get started!<\/p>\n<h3>ESXi 5.x Auto-STIG Scripts &#8211; Approach<\/h3>\n<p>Now that we understand what the STIG process is for ESXi 5.x and why we want to build our own, let\u2019s take a quick look at how we plan on getting this done.<\/p>\n<h4>ESXi 5.x Auto-STIG Scripts &#8211; Approach Overview<\/h4>\n<p>First, we want to concentrate on only those STIG checklist items that can be validated directly from the ESXi host. This might sound obvious &#8211; but it\u2019s not. When managing an ESXi host you have some options; you can run scripts directly on the ESXi host itself within the slimmed-down Linux <code>busybox<\/code> shell. You can run PowerCLI or PowerShell scripts against the ESXi host from your vCenter Server. If you have the VMware Management Appliance (vMA), you can run commands against the ESXi host from the vMA.<\/p>\n<p>For our use case we want to keep the process as simple as possible: we want to build our scripts to run directly on the ESXi host itself, with no dependencies on having a functional vCenter Server or vMA. This has some great advantages:<\/p>\n<ul>\n<li>We know that our scripts will run as-is on any ESXi host including a fresh install.<\/li>\n<li>We don\u2019t need to integrate with other system administrators on other vSphere components just to harden our script.<\/li>\n<li>We can harden our ESXi hosts in totally disconnected mode.<\/li>\n<\/ul>\n<p>These are all good things. But there are some problems:<\/p>\n<ul>\n<li>We can\u2019t check some of the &#8220;non-ESXi&#8221; STIG checklist items such as those checklist items that apply to distributed virtual switches or physical switchport interfaces.<\/li>\n<li>By default, not every change made by our hardening scripts will survive an ESXi host reboot (more on that further).<\/li>\n<li>Some of the hardening scripts get very complicated due to somewhat limited nature of the VMware tools installed on a vanilla ESXi host.<\/li>\n<\/ul>\n<p>The words &#8220;you pays your money, and you makes your choice&#8221; come to mind. While our approach of creating hardening scripts for use directly on the ESXi host, it simply means that we can\u2019t hit all of the 141 STIG checklist items. That\u2019s too bad, but it\u2019s life. We deal with it.<\/p>\n<h4>ESXi 5.x Auto-STIG Scripts &#8211; Approach Specifics<\/h4>\n<p>Our basic approach is this:<\/p>\n<ul>\n<li><strong>Perform only verifiable checks.<\/strong> In other words, many STIG checklist items are simply policy matters. We identified one (<code>ESXI5-VMNET-000001<\/code>, &#8220;All dvPortgroup VLAN IDs must be fully documented&#8221;) that we simply can\u2019t check via a script. Why not? Because policy-based STIG checklist items depend on things that exist outside of the ESXi host. For example, the <code>ESXI5-VMNET-000001<\/code> requires that you have an external document like a spreadsheet or database with a list of all of your used VLAN IDs. It also requires that you have a documented process for how VLAN IDs are modified, created, or deleted. None of this has anything to do with the actual ESXi host; all we can tell from the ESXi host is whether you use a particular VLAN ID. So we don\u2019t even bother with that STIG checklist item &#8211; and there are around 61 such &#8220;policy-only&#8221; checklist items. Instead, we concentrate on those STIG checklist items we can check for and possibly fix using standard VMware commands from tools such as <code>esxcli<\/code>.<\/li>\n<li><strong>Treat each STIG checklist item individually.<\/strong> Instead of writing one massive set of shell commands, we separate each STIG checklist item into its own specialized function. This allows us to test our STIG checklist scripts one at a time instead of just running the entire set of checks. As you\u2019ll see below, we go to some pains to make sure we can properly test our work prior to running the whole thing.<\/li>\n<li><strong>Ensure each STIG checklist script can be re-run non-destructively.<\/strong> This is a biggie&#8230;we do not want a solution where if by some unfortunate chance we re-run the script, the system administrator is put into an unknown state. Instead, we want each individual STIG checklist script to look for its condition and make a decision as to whether a &#8220;fix&#8221; should be performed. Consider checklist item <code>GEN003510-ESXI5-006660<\/code> (&#8220;Kernel core dumps must be disabled unless needed&#8221;): we first check to see if kernel core dumps are disabled and we take no action if they are. What this means is that on running the script a second time, it functions as simply a verification that the STIG checklist item is still in compliance.<\/li>\n<li><strong>Account for persistence.<\/strong> This is another biggie; by default, almost every change made to a running ESXi host is undone when the host is rebooted. (For more information, see William Lam\u2019s excellent write-ups on ESXi 4.x at http:\/\/www.virtuallyghetto.com\/2011\/08\/how-to-persist-configuration-changes-in.html (Part 1) and http:\/\/www.virtuallyghetto.com\/2011\/08\/how-to-persist-configuration-changes-in_09.html (Part 2).) This turned out to be a bit tricky for us, but it\u2019s important as otherwise key bits of STIG checklist items (such as running weekly baseline checks, or ensuring that login banners are correct) are &#8220;undone&#8221; upon a simple ESXi host reboot.<\/li>\n<li><strong>Make the scripts easy to apply.<\/strong> The best approach would be to have the ESXi STIG checklist automation scripts deployed as part of a VMware Information Bundle (&#8220;VIB&#8221;) and then apply the checklist items automatically on first boot. But we won\u2019t do that for this first cut; instead, we\u2019ll provide some relatively simple instructions on getting the scripts over to the ESXi host and then running them as necessary.<\/li>\n<\/ul>\n<p>All this sounds good, yes? So let\u2019s keep moving forward \ud83d\ude42<\/p>\n<h4>ESXi 5.x Auto-STIG Scripts &#8211; Standards \/ Common Code<\/h4>\n<p>We want to have standards for our automated STIG scripts, so we define the following:<\/p>\n<ul>\n<li><strong>Naming conventions.<\/strong> For our use case, we\u2019ll make every script named <code>esxi_stig_[XXX]<\/code> where the <code>[XXX]<\/code> identifies the specific function and the <code>esxi_stig_<\/code> prefix makes it easy to identify our particular scripts.<\/li>\n<li><strong>Common code.<\/strong> We want to minimize our work; for things like printing script status or common actions to update a configuration file, we want to use the same process all of the time. Let\u2019s take a look at what this means practically. For example, script output&#8230;we want a single function that outputs the result of a STIG checklist item analysis so that we can modify all output from a single location. This makes our code more manageable. For our use case, we named our common function esxi_stig_showresult and defined it as such:\n<pre><code>#######################################################################\r\n# show result of an effort\r\nesxi_stig_showresult() {\r\n  if [ \"$1\" = \"0\" ]; then\r\n    echo \"[ok]\"\r\n  else\r\n    if [ \"$1\" = \"1\" ]; then\r\n      echo \"Fixed!\"\r\n    else\r\n      if [ \"$1\" = \"2\" ]; then\r\n        echo \"[n\/a]\"\r\n      else\r\n        echo \"[ERROR!]\"\r\n      fi\r\n    fi\r\n  fi\r\n  return 0\r\n}<\/code><\/pre>\n<p>The advantages of this approach are that we can change our output logic once and have it apply to every checklist function consumer. We ended up with a number of functions that are similar in concept: updating common configuration files (<code>esxi_stig_updateconfig<\/code>); modifying an ESXi service to meet our needs (<code>esxi_stig_service_setup<\/code>); making common changes to the SSH configuration file (<code>esxi_stig_sshd_SimpleChange<\/code>); and, several others.<\/li>\n<li><strong>Documentation.<\/strong> We are big believers that if work isn\u2019t documented, it simply isn\u2019t complete. So our scripts need documentation all over the place. Consider the following:\n<pre><code>esxi_stig_SRG_OS_000120_ESXI5() {\r\n  l_rulename=\"SRG-OS-000120-ESXI5\"\r\n  l_first=1\r\n  echo -n \"$l_rulename...\"\r\n  l_FIXED=0\r\n\r\n  # first check to see if sha512 already in use\r\n  if grep \"^password[ \\t]\\+sufficient[ \\t]\" \/etc\/pam.d\/passwd | grep sha512 2>&amp;1 &gt;\/dev\/null; then\r\n    # it's OK\r\n    echo -n \"Using sha512...\"\r\n  else\r\n    # remove any others\r\n    l_FIXED=1\r\n    if cat \/etc\/pam.d\/passwd \\\r\n      | grep -e \"\\(^password[ \\t]\\+sufficient[ \\t]\\)\\(.*\\)\\(md5\\|des\\|sha256\\)\\(.*\\)\" \\\r\n      2&gt;&amp;1 >\/dev\/null; then\r\n      echo -n \"Replacing with sha512...\"\r\n      cat \/etc\/pam.d\/passwd \\\r\n        | sed -e \\\r\n        \"s#\\(^password[ \\t]\\+sufficient[ \\t]\\)\\(.*\\)\\(md5\\|des\\|sha256\\)\\(.*\\)#\\1\\2sha512\\4#g\" \\\r\n        &gt; \/etc\/pam.d\/passwd-new\r\n    else\r\n      echo -n \"Adding sha512...\"\r\n      cat \/etc\/pam.d\/passwd \\\r\n        | sed -e \"s#\\(^password[ \\t]\\+sufficient[ \\t].*\\)#\\1 sha512#g\" \\\r\n        &gt; \/etc\/pam.d\/passwd-new\r\n    fi\r\n    esxi_stig_updateconfig \/etc\/pam.d\/passwd\r\n  fi\r\n  esxi_stig_showresult ${l_FIXED}\r\n}<\/code><\/pre>\n<p>The above script checks to see if Secure Hash Algorithm (SHA) using 512 bits (&#8220;sha512&#8221;) is in use for incoming SSH connections. If it isn\u2019t, we update the SSH server configuration file to require it. We can tell all of this just by reading the code, and that is a good thing!<\/li>\n<\/ul>\n<p>There are plenty of other things we could do for standards, but the above is a good starting point and definitely highlights our good intentions \ud83d\ude42<\/p>\n<h3>ESXi 5.x Auto-STIG Scripts &#8211; Persistence<\/h3>\n<p>Ah, persistence. That turned out to be quite difficult for us to get right with many ESXi host reboots and false starts. But we solved it!<br \/>\nFirst the problem: by default, almost all changes to an ESXi host are discarded upon a reboot. This is a Good Thing for a hypervisor; it is a great security feature and helps to ensure that the hypervisor image itself remains as small as possible (after all, the image is effectively being laid down fresh on every boot). In fact, the only files which are &#8220;persistent&#8221; are those which meet the following criteria as documented in William Lam\u2019s article at http:\/\/www.virtuallyghetto.com\/2011\/08\/how-to-persist-configuration-changes-in.html:<\/p>\n<ul>\n<li>The file must have the &#8220;sticky&#8221; bit set.<\/li>\n<li>The file must have a backup copy created as &#8220;<code>.#[filename]<\/code>&#8220;.<\/li>\n<\/ul>\n<p>As William\u2019s post points out, this is not some that the user can do; instead, it\u2019s a function of the VisorFS. To find the files which meet this criteria, simply run the following command from the root folder:<br \/>\n<code>find etc -follow -type f -name \".#*\"<\/code><br \/>\nYou\u2019ll get quite a bit of output, such as &#8220;<code>etc\/rc.local.d\/#.local.sh<\/code>&#8221; (at least under ESXi 5.x). Each file listed will be persisted across ESXi host reboots&#8230;as long as the magic command &#8220;<code>\/sbin\/auto-backup.sh<\/code>&#8221; is run (William\u2019s post talks about this in greater detail). The auto-backup.sh command runs once every hour, so it\u2019s possible to lose up to 59 minutes worth of changes (normally, a clean reboot won\u2019t have this problem as <code>auto-backup.sh<\/code> is run automatically as part of a clean reboot).<\/p>\n<p>But this approach does mean that if we simply create files or folders then &#8211; upon an ESXi host reboot &#8211; we will *lose* those files \/ folders. Not such a good thing for the following reasons:<\/p>\n<ul>\n<li>Certain configuration files such as <code>\/etc\/banner<\/code> must be modified to meet STIG requirements, but these configuration files are *not saved* across reboots.<\/li>\n<li>If you depend on the existence of third-party (non-VMware) files across reboots such as to run <code>cron<\/code> scripts, you will be out of luck.<\/li>\n<\/ul>\n<p>So how do we solve this problem? Simple! We write our own special <code>esxi_stig_auto_persist<\/code> script function that makes sure our automated functions survive an ESXi host reboot. We first compress our scripts, copy that compressed image to the protected (and persistent) <code>\/bootbank<\/code> area, then modify the persistent <code>\/etc\/rc.local.d\/local.sh<\/code> file to decompress and process our scripts as necessary on each reboot. Here\u2019s the actual code:<\/p>\n<pre><code>esxi_stig_auto_persist() {\r\n  # name of the compressed file we use\r\n  l_compressed=esxi_stig.tgz\r\n  l_bootbank=\/bootbank\r\n  l_boot_cfg=boot.cfg\r\n  l_bootbank_boot_cfg=\"$l_bootbank\/$l_boot_cfg\"\r\n  l_bootbank_compressed=\"$l_bootbank\/$l_compressed\"\r\n  l_boot_cfg_new=\"$l_bootbank_boot_cfg-new\"\r\n  l_esxi_stig_sh='ESXi_STIG.sh'\r\n\r\n  # get the current folder\r\n  l_pwd=$PWD\r\n\r\n  # create the compressed file we store with ESXi\r\n  echo \"Creating compressed file $l_compressed...\"\r\n  rm -f $l_pwd\/$l_compressed\r\n  cd \/ && tar -czvf $l_pwd\/$l_compressed $l_pwd\/ESXi_STIG* 2&gt;\/dev\/null | sed -e 's\/^\/  ...\/' && cd $l_pwd\r\n\r\n  # copy to ESXi bootbank for persistent storage\r\n  echo \"Copying to $l_bootbank...\"\r\n  cp -f .\/$l_compressed $l_bootbank\r\n\r\n  # check to see if we are already in the boot.cfg script\r\n  if grep -e \"^modules=.* --- $l_compressed\" $l_bootbank_boot_cfg 2&gt;&amp;1 >\/dev\/null; then\r\n    echo \"[Already installed to $l_bootbank_boot_cfg...]\"\r\n  else\r\n    # learned from experience *not* to put a reference to the tgz file in boot.cfg\r\n    echo \"[Not modifying $l_bootbank_boot_cfg; this leads to boot failures...]\"\r\n    #echo \"Modifying $l_bootbank_boot_cfg to contain $l_compressed...\"\r\n    #cat $l_bootbank_boot_cfg | sed -e \"s\/^\\(modules=.*\\)\/\\1 --- $l_compressed\/\" &gt; $l_boot_cfg_new\r\n    #esxi_stig_updateconfig $l_bootbank_boot_cfg\r\n  fi\r\n\r\n  # now setup rc.local to update the banner\r\n  l_rclocal_tag=\"# -- esxi_stig_auto_persist\"\r\n  l_is_5_0=$(esxi_stig_is_ESXi_5_0)\r\n  if [ \"$l_is_5_0\" = \"1\" ]; then\r\n    l_etc_rc=\/etc\/rc.local\r\n  else\r\n    l_etc_rc=\/etc\/rc.local.d\/local.sh\r\n  fi\r\n  l_etc_rc_new=\"$l_etc_rc\"-new\r\n  echo \"Setting up $l_etc_rc_new to contain our startup commands...\"\r\n  grep -v -e \"$l_rclocal_tag\" $l_etc_rc | grep -v -e \"^exit 0\" &gt; $l_etc_rc_new\r\n  echo \"$l_rclocal_tag - BEGIN\" &gt;&gt; $l_etc_rc_new\r\n  echo \"l_pwd=\\$PWD $l_rclocal_tag\" >> $l_etc_rc_new\r\n  echo \"echo 'Uncompressing $l_compressed' $l_rclocal_tag\" &gt;&gt; $l_etc_rc_new\r\n  echo \"cd \/ $l_rclocal_tag\" &gt;&gt; $l_etc_rc_new\r\n  echo \"tar -xzf $l_bootbank_compressed $l_rclocal_tag\" &gt;&gt; $l_etc_rc_new\r\n  echo \"if [ -d '$l_pwd' -a -f '$l_pwd\/$l_esxi_stig_sh' ]; then $l_rclocal_tag\" &gt;&gt; $l_etc_rc_new\r\n  echo \"  echo 'Setting banners...' $l_rclocal_tag\" &gt;&gt; $l_etc_rc_new\r\n  echo \"  cd $l_pwd $l_rclocal_tag\" &gt;&gt; $l_etc_rc_new\r\n  echo \"  ESXI_STIG_DEFINE_ONLY=1 $l_rclocal_tag\" &gt;&gt; $l_etc_rc_new\r\n  echo \"  . $l_esxi_stig_sh $l_rclocal_tag\" &gt;&gt; $l_etc_rc_new\r\n  echo \"  esxi_stig_SRG_OS_000023_ESXI5 $l_rclocal_tag\" &gt;&gt; $l_etc_rc_new\r\n  echo \"  unset ESXI_STIG_DEFINE_ONLY $l_rclocal_tag\" &gt;&gt; $l_etc_rc_new\r\n  echo \"else $l_rclocal_tag\" &gt;&gt; $l_etc_rc_new\r\n  echo \"  echo 'Unable to uncompress $l_bootbank_compressed...check logs' $l_rclocal_tag\" &gt;&gt; $l_etc_rc_new\r\n  echo \"fi $l_rclocal_tag\" &gt;&gt; $l_etc_rc_new\r\n  echo \"cd \\$l_pwd $l_rclocal_tag\" &gt;&gt; $l_etc_rc_new\r\n  echo \"$l_rclocal_tag - END\" &gt;&gt; $l_etc_rc_new\r\n  if [ \"$l_is_5_0\" = \"0\" ]; then\r\n    # must put in an 'exit 0' for ESXi 5.x (not 5.0)\r\n    echo \"exit 0\" &gt;&gt; $l_etc_rc_new\r\n  fi\r\n  echo \"Updating $l_etc_rc...\"\r\n  esxi_stig_updateconfig $l_etc_rc\r\n\r\n  return 0\r\n}<\/code><\/pre>\n<p>That\u2019s a lot of code &#8211; but it\u2019s commented and performs exactly the actions described. The neat part is the update to <code>\/etc\/rc.local.d\/local.sh<\/code>, which is the equivalent of the old <code>AUTOEXEC.BAT<\/code> file in MS-DOS &#8211; it gets run automatically at boot so we can do things such as verify that we run the <code>esxi_stig_SRG_OS_000023_ESXI5<\/code> function to ensure that our banners are set correctly to meet DISA STIG requirements.<\/p>\n<p><strong>Note: <\/strong> You must copy this code down locally to run it&#8230;it&#8217;s not part of the ZIP file above. For your convenience, <\/p>\n<p>Last point &#8211; the magic function <code>esxi_stig_updateconfig<\/code> runs the auto-backup.sh process to make sure that our changes are persistent. In fact, we\u2019ll put in the <code>esxi_stig_updateconfig<\/code> function here just so you can see for yourself&#8230;it\u2019s quite instructive in its own right:<\/p>\n<pre><code>\r\n# update config file from -new\r\nesxi_stig_updateconfig() {\r\n  l_config=\"$1\"\r\n  l_config_new=\"$1\"-new\r\n\r\n  # check if file exists\r\n  l_perms=\"\"\r\n  l_chmod_perms=\"\"\r\n  if [ -f \"$l_config\" ]; then\r\n    # get orig file permissions\r\n    l_perms=$(ls -la \"$l_config\" | cut -d ' ' -f 1)\r\n\r\n    # xlat to octal\r\n    l_chmod_perms=$(esxi_stig_xlat_perms \"$l_perms\")\r\n\r\n    # save the config file\r\n    esxi_stig_saveconfig \"$l_config\"\r\n  fi\r\n\r\n  # copy the new if given\r\n  if [ -f \"$l_config_new\" ]; then\r\n    cp -f \"$l_config_new\" \"$l_config\"\r\n    rm -f \"$l_config_new\"\r\n\r\n    # set permissions and indicate that problem was \"fixed\" via return code\r\n    if [ ! \"$l_chmod_perms\" = \"\" ]; then\r\n      chmod $l_chmod_perms \"$l_config\"\r\n    fi\r\n    return 1\r\n  fi\r\n  # make changes persistent\r\n  \/sbin\/auto-backup.sh 2&gt;&amp;1 >\/dev\/null\r\n\r\n  # FIXME: indicate \"fixed\" in any event\r\n  return 1\r\n}<\/code><\/pre>\n<p>And with this, we\u2019ve covered all the groundwork and now we can discuss how to apply the auto-STIG scripts.<\/p>\n<h3>ESXi 5.x Auto-STIG Scripts &#8211; Policy Checklist Items<\/h3>\n<p>Before we present the complete solution to running the auto-STIG scripts, let\u2019s jump back to these &#8220;policy-only&#8221; STIG checklist items. These are items which must meet the following criteria:<\/p>\n<ul>\n<li>They are specifically addressed by the system administrator.<\/li>\n<li>There is a formal (written) policy on how the checklist item is to be managed.<\/li>\n<li>There is a defined process that demonstrates how the STIG checklist item is managed.<\/li>\n<\/ul>\n<p>We&#8217;re not going to cover all of these requirements here; the wise system administrator knows to perform these steps in any case as they are simply common sense. Instead, we quickly cover the &#8220;policy-only&#8221; STIG checklist items along with our simple policy statement. You\u2019ll notice that we generally refer to other documents where appropriate (for example, our &#8220;Server Functions.docx&#8221; document covers a lot of material, and &#8220;Tech Guide.docx&#8221; covers much of the rest) or we reference how we address the STIG checklist item directly in the table. The key takeaway here? Be sure you can defend your hardening approach to your local IAM!<\/p>\n<table>\n<thead>\n<tr>\n<td><strong>STIG Checklist Item<\/strong><\/td>\n<td><strong>Addressed How?<\/strong><\/td>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>GEN007740-ESXI5-000118<\/td>\n<td>IPv6 explicitly disabled on each ESXi host<\/td>\n<\/tr>\n<tr>\n<td>GEN007700-ESXI5-000116<\/td>\n<td>IPv6 explicitly disabled on each ESXi host<\/td>\n<\/tr>\n<tr>\n<td>GEN000240-ESXI5-000058<\/td>\n<td>NTP servers set as documented in Server Functions.docx<\/td>\n<\/tr>\n<tr>\n<td>GEN000100-ESXI5-000062<\/td>\n<td>ESXi servers patched as documented in this Guide.<\/td>\n<\/tr>\n<tr>\n<td>GEN008680-ESXI5-000056<\/td>\n<td>Removable media not used for booting ESXi hosts except for initial install or major upgrade. Disabled within BIOS.<\/td>\n<\/tr>\n<tr>\n<td>GEN001375-ESXI5-000086<\/td>\n<td>At least 2 name servers used as documented in Server Functions.docx.<\/td>\n<\/tr>\n<tr>\n<td>ESXI5-VMNET-000024<\/td>\n<td>Management network separated from VM network as documented in Tech Guide.docx.<\/td>\n<\/tr>\n<tr>\n<td>ESXI5-VMNET-000023<\/td>\n<td>Management network separated from VM network as documented in Tech Guide.docx.<\/td>\n<\/tr>\n<tr>\n<td>SRG-OS-000231-ESXI5<\/td>\n<td>Remote connections set as required within Tech Guide.docx.<\/td>\n<\/tr>\n<tr>\n<td>SRG-OS-000152-ESXI5<\/td>\n<td>Host-based boundaries set as required within Tech Guide.docx.<\/td>\n<\/tr>\n<tr>\n<td>SRG-OS-000145-ESXI5<\/td>\n<td>Default router set as required within Tech Guide.docx.<\/td>\n<\/tr>\n<tr>\n<td>SRG-OS-000132<\/td>\n<td>Management traffic is set to VLAN 210 (Tech Guide.docx)<\/td>\n<\/tr>\n<tr>\n<td>SRG-OS-000109-ESXI5<\/td>\n<td>Special note about <code>root<\/code> login access via SSH given with Tech Guide.docx.<\/td>\n<\/tr>\n<tr>\n<td>SRG-OS-99999-ESXI5-000138<\/td>\n<td>Special note about enabling SSH access given with Tech Guide.docx.<\/td>\n<\/tr>\n<tr>\n<td>SRG-OS-000090-ESXI5<\/td>\n<td>Addressed within Tech Guide.docx during ESXi host setup.<\/td>\n<\/tr>\n<tr>\n<td>SRG-OS-000092-ESXI5<\/td>\n<td>Lockdown mode addressed via policy within Tech Guide.docx.<\/td>\n<\/tr>\n<tr>\n<td>GEN008600-ESXI5-000050<\/td>\n<td>Addressed within Tech Guide.docx during ESXi host setup.<\/td>\n<\/tr>\n<tr>\n<td>SRG-OS-000056-ESXI5<\/td>\n<td>Time servers are local to enclave, tied to DoD timeservers. See Tech Guide.docx.<\/td>\n<\/tr>\n<tr>\n<td>SRG-OS-000080-ESXI5<\/td>\n<td>BIOS passwords are set as specified in Tech Guide.docx.<\/td>\n<\/tr>\n<tr>\n<td>GEN008640-ESXI5-000055<\/td>\n<td>BIOS bootloader set as specified in Tech Guide.docx.<\/td>\n<\/tr>\n<tr>\n<td>GEN005460-ESXI5-000060<\/td>\n<td>SYSLOG is set for each ESXi host as specified in Tech Guide.docx.<\/td>\n<\/tr>\n<tr>\n<td>GEN005440-ESXI5-000078<\/td>\n<td>Same steps as for GEN005460-ESXI5-000060.<\/td>\n<\/tr>\n<tr>\n<td>GEN008460-ESXI5-000121<\/td>\n<td>Disable USB devices within BIOS as specified in Tech Guide.docx.<\/td>\n<\/tr>\n<tr>\n<td>GEN008480-ESXI5-000122<\/td>\n<td>Same steps as for GEN008460-ESXI5-000121.<\/td>\n<\/tr>\n<tr>\n<td>GEN008500-ESXI5-000123<\/td>\n<td>Firewire disabled within BIOS as specified in Tech Guide.docx.<\/td>\n<\/tr>\n<tr>\n<td>SRG-OS-99999-ESXI5-000139<\/td>\n<td>Setup CIM access as specified in Tech Guide.docx.<\/td>\n<\/tr>\n<tr>\n<td>SRG-OS-99999-ESXI5-000141<\/td>\n<td>iSCSI access (software and hardware) must use bidirectional CHAP even on an isolated network &#8211; this is by policy.<\/td>\n<\/tr>\n<tr>\n<td>SRG-OS-99999-ESXI5-000143<\/td>\n<td>Use SSL for Network File Copy within the vCenter Server (this is *not* applicable to individual ESXi hosts).<\/td>\n<\/tr>\n<tr>\n<td>SRG-OS-99999-ESXI5-000145<\/td>\n<td>The default vpxuser user auto-password change is 30 days &#8211; leave this at that value.<\/td>\n<\/tr>\n<tr>\n<td>SRG-OS-99999-ESXI5-000146<\/td>\n<td>Leave the vpxuser password length at default of 32.<\/td>\n<\/tr>\n<tr>\n<td>SRG-OS-99999-ESXI5-000147<\/td>\n<td>Per policy: iSCSI access (software and hardware) must use unique CHAP authentication secrets for each host.<\/td>\n<\/tr>\n<tr>\n<td>SRG-OS-99999-ESXI5-000150<\/td>\n<td>If fibre channel is used, setup LUN masking appropriately.<\/td>\n<\/tr>\n<tr>\n<td>SRG-OS-99999-ESXI5-000151<\/td>\n<td>Set dvFilter masking appropriately based on whether a dvfilter-based network security appliance is in use.<\/td>\n<\/tr>\n<tr>\n<td>SRG-OS-99999-ESXI5-000160<\/td>\n<td>Policy is to use vSphere Authentication Proxy when an Active Directory domain is used.<\/td>\n<\/tr>\n<tr>\n<td>SRG-OS-99999-ESXI5-000161<\/td>\n<td>When deleting VMDK files, the policy is to use either vmkfstools &#8211;writezeroes <path+vmdk_flat_file> or dd if=\/dev\/zero of=<path+vmdk_flat_file><\/td>\n<\/tr>\n<tr>\n<td>ESXI5-VMNET-000001<\/td>\n<td>Fully document the use of all VLAN IDs<\/td>\n<\/tr>\n<tr>\n<td>ESXI5-VMNET-000002<\/td>\n<td>All private VLAN IDs must be documented.<\/td>\n<\/tr>\n<tr>\n<td>ESXI5-VMNET-000003<\/td>\n<td>All virtual switches must have a clear network label and documentation.<\/td>\n<\/tr>\n<tr>\n<td>ESXI5-VMNET-000004<\/td>\n<td>Virtual switch VLAN IDs must be fully documented and only required VLANs used.<\/td>\n<\/tr>\n<tr>\n<td>ESXI5-VMNET-000005<\/td>\n<td>All vSwitch \/ VLAN IDs must be fully documented.<\/td>\n<\/tr>\n<tr>\n<td>ESXI5-VMNET-000006<\/td>\n<td>Isolate storage traffic to a dedicated physical adaptor.<\/td>\n<\/tr>\n<tr>\n<td>ESXI5-VMNET-000036<\/td>\n<td>All IP-based storage traffic must be isolated to a management-only network using a dedicated, management-only vSwitch.<\/td>\n<\/tr>\n<tr>\n<td>ESXI5-VMNET-000046<\/td>\n<td>All IP-based storage traffic must be isolated using a vSwitch containing management-only port groups.<\/td>\n<\/tr>\n<tr>\n<td>ESXI5-VMNET-000007<\/td>\n<td>Only authorized administrators must have access to virtual networking components.<\/td>\n<\/tr>\n<tr>\n<td>ESXI5-VMNET-000008<\/td>\n<td>All physical switch ports must be configured with spanning tree disabled.<\/td>\n<\/tr>\n<tr>\n<td>ESXI5-VMNET-000009<\/td>\n<td>All port groups must be configured with a clear network label.<\/td>\n<\/tr>\n<tr>\n<td>ESXI5-VMNET-000014<\/td>\n<td>Cannot be checked within script from ESXi host; all dvsPortgroups must be set not to be promiscuous. The default setting is secure.<\/td>\n<\/tr>\n<tr>\n<td>ESXI5-VMNET-000015<\/td>\n<td>Cannot be checked within script from ESXi host; all dvsPortgroups must be set not to permit MAC address changes. The default setting is secure.<\/td>\n<\/tr>\n<tr>\n<td>ESXI5-VMNET-000017<\/td>\n<td>Non-negotiate option to external switches cannot be verified from ESXi hosts.<\/td>\n<\/tr>\n<tr>\n<td>ESXI5-VMNET-000020<\/td>\n<td>Unable to determine the number of VM NICs attached to a dvPortgroup from a single ESXi host; dvPortgroup usage must be analyzed based upon the vCenter Server settings.<\/td>\n<\/tr>\n<tr>\n<td>ESXI5-VMNET-000021<\/td>\n<td>vMotion isolation cannot be determined from an ESXi host as vMotion can be enabled on dvSwitch. Policy is that vMotion traffic is always isolated.<\/td>\n<\/tr>\n<tr>\n<td>ESXI5-VMNET-000025<\/td>\n<td>STP \/ Portfast settings on physical switches cannot be checked from ESXi host. Policy is that virtual machines that route or bridge traffic must have spanning tree protocol enabled and BPDU guard \/ Portfast disabled on upstream physical switch ports.<\/td>\n<\/tr>\n<tr>\n<td>ESXI5-VMNET-000026<\/td>\n<td>VDS dvPortgroup auto-expand option cannot be determined from the ESXi host. Policy is that the system must disable the autoexpand option for VDS dvPortgroups.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>With policy STIG checklist items out of the way, let\u2019s get onto auto-STIG scripts themselves.<\/p>\n<h3>ESXi 5.x Auto-STIG Scripts &#8211; Script Table of Content<\/h3>\n<p>This section describes the auto-STIG scripts created for hardening ESXi 5.x hosts. The scripts are portable to ESXi 5.0 and ESXi 5.x &#8211; which are *different* in key aspects. For example, persistent commands on ESXi 5.0 are stored in <code>\/etc\/rc.local<\/code> while ESXi 5.x uses <code>\/etc\/rc.local.d\/local.sh<\/code> &#8211; so the hardening scripts must account for this difference.<\/p>\n<ul>\n<li>Get scripts from the designated archive folder; check with the System Administrator for your enclave.<\/li>\n<li>Copy the following shell script files to the ESXi host; this requires SSH to be enabled:\n<ul>\n<li>ESXi_STIG.sh &#8211; Main script that applies STIG checklist items.<\/li>\n<li>ESXi_STIG_WeeklyTasks.sh &#8211; Driver script to setup weekly tasks such as checking for baseline changes.<\/li>\n<li>ESXi_STIG_WeeklyTasks_setgidCheck.sh &#8211; Support script: Verifies that group ID (&#8220;GID&#8221;) is set correctly.<\/li>\n<li>ESXi_STIG_WeeklyTasks_setuidCheck.sh &#8211; Support script: Verifies that user ID (&#8220;UID&#8221;) is set correctly.<\/li>\n<\/ul>\n<\/li>\n<li>Run the ESXi_STIG.sh script and capture output. It identifies the STIG checklist ID as well as whether a change was required or not. Sample output from one command is shown for <code>SRG_OS_000069_ESXI5<\/code> (&#8220;The system must require that passwords contain at least one uppercase alphabetic character.&#8221;):\n<pre><code>\/STIG # esxi_stig_SRG_OS_000069_ESXI5\r\nSRG-OS-000069-ESXI5...[ok]\r\n<\/code><\/pre>\n<p>The results can be verified by reviewing the STIG checklist, in the example case it is that the <code>\/etc\/pam.d\/passwd<\/code> file is properly updated.<\/li>\n<li>On the vCenter Server, copy the following PowerShell files:\n<ul>\n<li>ps_utils.ps1 &#8211; Utility program to setup PowerShell functions used by the auto-STIG scripts.<\/li>\n<li>esx_host_baseline.ps1 &#8211; Runs weekly tasks to verify that baseline ESXi files have not changed since the preceding check.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>The next section details a typical auto-STIG script installation.<\/p>\n<h3>ESXi 5.x Auto-STIG Scripts &#8211; Typical Install Case<\/h3>\n<p>This section uses screenshots to guide the system administrator through an actual installation.<\/p>\n<ul>\n<li><strong>Install the ESXi hypervisor.<\/strong> For our use case we configured HDS Blades to run ESXi 5.5 with all VMware service packs installed. We have already taken care of switch configurations to permit controlled access to the management interface, setup a root password, and applied IP addresses \/ hostnames as necessary.<\/li>\n<li><strong>Setup NTP Time Server.<\/strong>  This is a STIG requirement but not one we do automatically. You have an NTP server you connect to, correct? (Hint: The proper answer is &#8220;Yes, Sir!&#8221;). Here\u2019s a screenshot of NTP set correctly to an enclave-local time server:<br \/>\n<a href=\"\/wordpress\/wp-content\/uploads\/2014\/03\/ESXi_AutoStig_Screenshot_10.png\"><img loading=\"lazy\" decoding=\"async\" src=\"\/wordpress\/wp-content\/uploads\/2014\/03\/ESXi_AutoStig_Screenshot_10.png\" alt=\"ESXi_AutoStig_Screenshot_10\" width=\"733\" height=\"122\" class=\"alignnone size-full wp-image-683\" \/><\/a><\/li>\n<li><strong>Enable SSH access.<\/strong> This is a common requirement; simply login to the Direct Console User Interface (DCUI) and select the Troubleshooting Options, then select to Enable SSH. See the screenshot:<br \/>\n<a =\"\/wordpress\/wp-content\/uploads\/2014\/03\/ESXi_AutoStig_Screenshot_20.png\"><img loading=\"lazy\" decoding=\"async\" src=\"\/wordpress\/wp-content\/uploads\/2014\/03\/ESXi_AutoStig_Screenshot_20.png\" alt=\"ESXi_AutoStig_Screenshot_20\" width=\"627\" height=\"169\" class=\"alignnone size-full wp-image-685\" \/><\/a><\/li>\n<li><strong>Copy the auto-STIG scripts.<\/strong> We used WinSCP; follow these substeps:\n<ul>\n<li>Connect as root &#8211; this is an IA finding, but it will be corrected soon.<\/li>\n<li>Create the \/STIG folder and copy the files. A screenshot is presented with the files in place.<br \/>\n<a href=\"\/wordpress\/wp-content\/uploads\/2014\/03\/ESXi_AutoStig_Screenshot_30.png\"><img loading=\"lazy\" decoding=\"async\" src=\"\/wordpress\/wp-content\/uploads\/2014\/03\/ESXi_AutoStig_Screenshot_30.png\" alt=\"ESXi_AutoStig_Screenshot_30\" width=\"588\" height=\"162\" class=\"alignnone size-full wp-image-686\" \/><\/a><\/li>\n<li>Set the &#8220;Execute&#8221; bit for each copied file. Once again, this is detailed below:<br \/>\n<a href=\"\/wordpress\/wp-content\/uploads\/2014\/03\/ESXi_AutoStig_Screenshot_40.png\"><img loading=\"lazy\" decoding=\"async\" src=\"\/wordpress\/wp-content\/uploads\/2014\/03\/ESXi_AutoStig_Screenshot_40.png\" alt=\"ESXi_AutoStig_Screenshot_40\" width=\"445\" height=\"543\" class=\"alignnone size-full wp-image-687\" \/><\/a><\/li>\n<\/ul>\n<li><strong>Connect using SSH Client.<\/strong> In our case we used the PuTTY client which you can find for download, but there are a lot of SSH clients available. Connect in as root and then follow these steps:\n<ul>\n<li><em>Change to the <code>\/STIG<\/code> folder.<\/em> Use the command:<br \/>\n<code>cd \/STIG<\/code><\/li>\n<li><em>Verify the <code>\/STIG<\/code> folder contents.<\/em> Check out the following command and output, which shows that the files are copied over and have the execute bit set as necessary.\n<pre><code>\r\n\/STIG # <strong>ls -la<\/strong>\r\ntotal 84\r\ndrwxr-xr-x    1 root     root           512 Mar 14 13:58 .\r\ndrwxr-xr-x    1 root     root           512 Mar 14 13:59 ..\r\n-rwxr-xr-x    1 root     root         64844 Mar 14 12:23 ESXi_STIG.sh\r\n-rwxr-xr-x    1 root     root          2819 Mar 13 21:05 ESXi_STIG_WeeklyTasks.sh\r\n-rwxr-xr-x    1 root     root          1509 Sep 20 13:32 ESXi_STIG_WeeklyTasks_setgidCheck.sh\r\n-rwxr-xr-x    1 root     root          1539 Sep 18 14:59 ESXi_STIG_WeeklyTasks_setuidCheck.sh\r\n<\/code><\/pre>\n<\/li>\n<\/ul>\n<\/li>\n<li><strong>Run the Auto-STIG Scripts.<\/strong> Now we actually get to exercise the functions we\u2019ve discussed:\n<ul>\n<li><em>Load in the Auto-STIG Script Definitions.<\/em> This is a two-step process. We first set a flag that we do *not* want the scripts to fire, then we &#8220;source&#8221; in the scripts:\n<pre><code>\r\n\/STIG # <strong>ESXI_STIG_DEFINE_ONLY=1<\/strong>\r\n\/STIG # <strong>source .\/ESXi_STIG.sh<\/strong>\r\n<\/code><\/pre>\n<\/li>\n<li><em>Setup ESXi Host Reboot Persistence.<\/em> We have a special command to verify that our auto-STIG scripts survive ESXi host reboots properly. Let\u2019s run it now with the output displayed:\n<pre><code>\r\n\/STIG # <strong>esxi_stig_auto_persist<\/strong>\r\nCreating compressed file esxi_stig.tgz...\r\n  ...STIG\/ESXi_STIG.sh\r\n  ...STIG\/ESXi_STIG_WeeklyTasks.sh\r\n  ...STIG\/ESXi_STIG_WeeklyTasks_setgidCheck.sh\r\n  ...STIG\/ESXi_STIG_WeeklyTasks_setuidCheck.sh\r\nCopying to \/bootbank...\r\n[Not modifying \/bootbank\/boot.cfg; this leads to boot failures...]\r\nSetting up \/etc\/rc.local.d\/local.sh-new to contain our startup commands...\r\nUpdating \/etc\/rc.local.d\/local.sh...\r\n<\/code><\/pre>\n<p>This process does a lot of work on our behalf, including setting up the <code>\/etc\/rc.local.d\/local.sh<\/code> file to recreate our <code>\/STIG<\/code> folder and do any required work on a new ESXi host reboot. Let\u2019s take a quick peek at what got created in <code>\/etc\/rc.local.d\/local.sh<\/code>:<br \/>\n<code><\/p>\n<pre>\r\n\/STIG # <strong>cat \/etc\/rc.local.d\/local.sh<\/strong>\r\n#!\/bin\/sh\r\n\r\n# local configuration options\r\n\r\n# Note: modify at your own risk!  If you do\/use anything in this\r\n# script that is not part of a stable API (relying on files to be in\r\n# specific places, specific tools, specific output, etc) there is a\r\n# possibility you will end up with a broken system after patching or\r\n# upgrading.  Changes are not supported unless under direction of\r\n# VMware support.\r\n\r\n<em># -- esxi_stig_auto_persist - BEGIN\r\nl_pwd=$PWD # -- esxi_stig_auto_persist\r\necho \u2018Uncompressing esxi_stig.tgz\u2019 # -- esxi_stig_auto_persist\r\ncd \/ # -- esxi_stig_auto_persist\r\ntar -xzf \/bootbank\/esxi_stig.tgz # -- esxi_stig_auto_persist\r\nif [ -d \u2018\/STIG\u2019 -a -f \u2018\/STIG\/ESXi_STIG.sh\u2019 ]; then # -- esxi_stig_auto_persist\r\n  echo \u2018Setting banners...\u2019 # -- esxi_stig_auto_persist\r\n  cd \/STIG # -- esxi_stig_auto_persist\r\n  ESXI_STIG_DEFINE_ONLY=1 # -- esxi_stig_auto_persist\r\n  . ESXi_STIG.sh # -- esxi_stig_auto_persist\r\n  esxi_stig_SRG_OS_000023_ESXI5 # -- esxi_stig_auto_persist\r\n  unset ESXI_STIG_DEFINE_ONLY # -- esxi_stig_auto_persist\r\nelse # -- esxi_stig_auto_persist\r\n  echo \u2018Unable to uncompress \/bootbank\/esxi_stig.tgz...check logs\u2019 # -- esxi_stig_auto_persist\r\nfi # -- esxi_stig_auto_persist\r\ncd $l_pwd # -- esxi_stig_auto_persist\r\n# -- esxi_stig_auto_persist - END<\/em>\r\nexit 0\r\n<\/code><\/pre>\n<p>We\u2019ve marked the changes we made with italics. Note that each line has a \"tag\" associated with it (the \"<code>-- esxi_stig_auto_persist<\/code>\" on each line). This allows us to identify the changes we made and update the file *in-place* if we need to re-run the auto-STIG scripts. Basically, what these commands do are first to look for the compressed ESXi STIG archive, uncompress it, then re-run the special <code>esxi_stig_SRG_OS_000023_ESXI5<\/code> script to ensure that all banners are updated correctly for the ESXi host. It\u2019s a lot of steps, but it works well \ud83d\ude42\n<\/li>\n<li><em>Apply the STIG checklist items.<\/em> This is the money shot and the goal of our hard work. We get lots of STIG checklist items completed with a status for each one. Let\u2019s take a look:\n<pre><code>\r\n\/STIG # <strong>unset ESXI_STIG_DEFINE_ONLY<\/strong>\r\n\/STIG # <strong>.\/ESXi_STIG.sh<\/strong>\r\nGEN002420-ESXI5-00878...[n\/a]\r\nGEN002430-ESXI5...[n\/a]\r\nGEN003510-ESXI5-006660...Fixed!\r\nGEN005300-ESXI5-000099...[ok]\r\nSRG-OS-000112-ESXI5...Updating \/etc\/ssh\/ssh_config...Fixed!\r\n\r\n<em>[...output cut...]<\/em>\r\n\r\nGEN007700-ESXI5-000116...ESXi host reboot necessary...Fixed!\r\n\r\n<em>[...output cut...]<\/em>\r\n\r\nGEN000945-ESXI5-000333...[ok]\r\nSRG-OS-000152-ESXI5...Disable \u2018All IPs\u2019: CIMHttpServer,CIMHttpsServer,CIMSLP,sshServer,vSphereClient,webAccess...[ERROR!]\r\n<\/code><\/pre>\n<p>We cut a lot of the output, but there\u2019s enough left for you to get the idea. If we could fix something, we did. If we couldn\u2019t (such as <code>SRG-OS-000152-ESXI5<\/code>, which has to do with firewall rules) then we output the problems we found and indicate that it\u2019s an error. If we performed a fix that requires an ESXi host reboot (such as <code>GEN007700-ESXI5-000116<\/code>, which disables IPv6 support) then we tell you.\n<\/li>\n<li><em>Setup weekly tasks.<\/em> Our scripts do even more - some of the STIG checklist items require the system administrator to maintain ESXi host baselines so that any unauthorized file changes can be detected. We handle this by creating, persisting, and automatically-executing scheduled tasks to perform these baselines. Let\u2019s see what we do:\n<pre><code>\r\n\/STIG # <strong>source .\/ESXi_STIG_WeeklyTasks.sh<\/strong>\r\n\/STIG # <strong>esxi_stig_weekly_setup<\/strong>\r\nAdding: \/STIG\/ESXi_STIG_WeeklyTasks_setuidCheck.sh\r\nKilling cron with pid 33750...\r\nRestarting cron...\r\nAdding to \/etc\/rc.local.d\/local.sh...\r\nAdding: \/STIG\/ESXi_STIG_WeeklyTasks_setgidCheck.sh\r\nKilling cron with pid 39833...\r\nRestarting cron...\r\nAdding to \/etc\/rc.local.d\/local.sh...\r\n<\/code><\/pre>\n<p>Now...we don\u2019t *do* anything with these baselines or if we detect a baseline change - that\u2019s something that falls to you as the system administrator. However, you can simply check the contents of the <code>\/var\/log\/setgid<\/code> and the <code>\/var\/log\/setuid<\/code> folders from a vCenter Server script to take action if a failure is detected. Also, take  a look at the output from how we write to the cron file for root:<\/p>\n<pre><code>\r\n\/STIG # <strong>cat \/var\/spool\/cron\/crontabs\/root<\/strong>\r\n#min hour day mon dow command\r\n1    1    *   *   *   \/sbin\/tmpwatch.py\r\n1    *    *   *   *   \/sbin\/auto-backup.sh\r\n0    *    *   *   *   \/usr\/lib\/vmware\/vmksummary\/log-heartbeat.py\r\n*\/5  *    *   *   *   \/sbin\/hostd-probe ++group=host\/vim\/vmvisor\/hostd-probe\r\n# Fri Mar 14 18:56:23 UTC 2014 : added by esxi_stig_weekly_setupcron\r\n5 8 * * 6 \/STIG\/ESXi_STIG_WeeklyTasks_setuidCheck.sh\r\n# Fri Mar 14 18:56:25 UTC 2014 : added by esxi_stig_weekly_setupcron\r\n7 8 * * 6 \/STIG\/ESXi_STIG_WeeklyTasks_setgidCheck.sh\r\n<\/code><\/pre>\n<p>See how we added the two tasks and identified our work? Once again, this allows us to detect whether we\u2019ve already performed our work if the scripts must be run again.\n<\/li>\n<li><em>Make sure changes are stored persistently.<\/em> Our scripts go to a lot of trouble to run the <code>\/sbin\/auto-backup.sh<\/code> script when necessary. However, it does *not* hurt to run it again manually! Let\u2019s do that now:\n<pre><code>\r\n\/STIG # <strong>\/sbin\/auto-backup.sh<\/strong>\r\n--- \/etc\/ssh\/sshd_config\r\n+++ \/tmp\/auto-backup.38889\/\/etc\/ssh\/sshd_config\r\n@@ -59,7 +59,6 @@\r\n # SRG-OS-000027-ESXI5\r\n MaxSessions 1\r\n # SRG-OS-000109-ESXI5\r\n+PermitRootLogin yes\r\n # SRG-OS-000250-ESXI5\r\n Macs hmac-sha1\r\n-# SRG-OS-000109-ESXI5\r\n-PermitRootLogin no\r\nSaving current state in \/bootbank\r\nClock updated.\r\nTime: 19:58:23   Date: 03\/14\/2014   UTC\r\n<\/code><\/pre>\n<p>Do you see what we do? There were some unsaved changes...and now we know - for sure - that all of our changes are saved persistently.\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>At this point we are done - we have our STIG checks performed, and our ESXi host is patiently waiting for us to reboot it (due to the IPv6 change). So let\u2019s do the reboot and quickly verify that we continue to have all of our files in place. Upon the reboot you\u2019ll notice lots of changes already:<\/p>\n<ul>\n<li>You can\u2019t login to the DCUI.<\/li>\n<li>You can\u2019t login via SSH.<\/li>\n<\/ul>\n<p>Now you can \"fix\" the DCUI login by enabling DCUI access (although this is a STIG finding). However, even if you enable SSH access...you won\u2019t be able to login \ud83d\ude42 That\u2019s right, we disabled root access to SSH so you\u2019d have to create a local user and give it permissions in the root group. That\u2019s the price of security with ESXi 5.x.<\/p>\n<p>Happy computing!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>To run an ESXi 5.x host in a secure network requires the system to be compliant to all Information Assurance (IA) requirements. This article describes in detail how an automated hardening process was created to meet Defense Information Systems Agency &hellip;<\/p>\n<p class=\"read-more\"> <a class=\"more-link\" href=\"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/\"> <span class=\"screen-reader-text\">Auto-Harden ESXi 5.x Hosts<\/span> Read More &raquo;<\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[63,1,11],"tags":[16,13,22,18,20],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v22.2 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>Auto-Harden ESXi 5.x Hosts - softwareab<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Auto-Harden ESXi 5.x Hosts - softwareab\" \/>\n<meta property=\"og:description\" content=\"To run an ESXi 5.x host in a secure network requires the system to be compliant to all Information Assurance (IA) requirements. This article describes in detail how an automated hardening process was created to meet Defense Information Systems Agency &hellip; Auto-Harden ESXi 5.x Hosts Read More &raquo;\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/\" \/>\n<meta property=\"og:site_name\" content=\"softwareab\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/cloudraticsolutions\/\" \/>\n<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/cloudraticsolutions\/\" \/>\n<meta property=\"article:published_time\" content=\"2014-03-19T19:26:39+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2014-06-04T15:57:31+00:00\" \/>\n<meta name=\"author\" content=\"Andrew Bruce\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@realcloudratics\" \/>\n<meta name=\"twitter:site\" content=\"@realcloudratics\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Andrew Bruce\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"36 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/\"},\"author\":{\"name\":\"Andrew Bruce\",\"@id\":\"https:\/\/www.softwareab.net\/wordpress\/#\/schema\/person\/1337443eaeb75104e0410b508e67f600\"},\"headline\":\"Auto-Harden ESXi 5.x Hosts\",\"datePublished\":\"2014-03-19T19:26:39+00:00\",\"dateModified\":\"2014-06-04T15:57:31+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/\"},\"wordCount\":5586,\"commentCount\":51,\"publisher\":{\"@id\":\"https:\/\/www.softwareab.net\/wordpress\/#\/schema\/person\/1337443eaeb75104e0410b508e67f600\"},\"keywords\":[\"dod\",\"ia\",\"scripting\",\"sysadmin\",\"vmware\"],\"articleSection\":[\"Information Assurance\",\"Teknocratica\",\"VMware\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/\",\"url\":\"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/\",\"name\":\"Auto-Harden ESXi 5.x Hosts - softwareab\",\"isPartOf\":{\"@id\":\"https:\/\/www.softwareab.net\/wordpress\/#website\"},\"datePublished\":\"2014-03-19T19:26:39+00:00\",\"dateModified\":\"2014-06-04T15:57:31+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.softwareab.net\/wordpress\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"dod\",\"item\":\"https:\/\/www.softwareab.net\/wordpress\/tag\/dod\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Auto-Harden ESXi 5.x Hosts\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.softwareab.net\/wordpress\/#website\",\"url\":\"https:\/\/www.softwareab.net\/wordpress\/\",\"name\":\"softwareab\",\"description\":\"Technocratica, Technopolitik, Technophobia\",\"publisher\":{\"@id\":\"https:\/\/www.softwareab.net\/wordpress\/#\/schema\/person\/1337443eaeb75104e0410b508e67f600\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.softwareab.net\/wordpress\/?s={search_term_string}\"},\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"en-US\"},{\"@type\":[\"Person\",\"Organization\"],\"@id\":\"https:\/\/www.softwareab.net\/wordpress\/#\/schema\/person\/1337443eaeb75104e0410b508e67f600\",\"name\":\"Andrew Bruce\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.softwareab.net\/wordpress\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/www.softwareab.net\/wordpress\/wp-content\/uploads\/2024\/03\/andy-cartoon.jpg\",\"contentUrl\":\"https:\/\/www.softwareab.net\/wordpress\/wp-content\/uploads\/2024\/03\/andy-cartoon.jpg\",\"width\":400,\"height\":330,\"caption\":\"Andrew Bruce\"},\"logo\":{\"@id\":\"https:\/\/www.softwareab.net\/wordpress\/#\/schema\/person\/image\/\"},\"description\":\"Team-oriented systems mentor with deep knowledge of numerous software methodologies, technologies, languages, and operating systems. Excited about turning emerging technology into working production-ready systems. Focused on moving software teams to a higher level of world-class application development. Specialties:Software analysis and development...Product management through the entire lifecycle...Discrete product integration specialist!\",\"sameAs\":[\"http:\/\/cloudraticsolutions.net\/\",\"https:\/\/www.facebook.com\/cloudraticsolutions\/\",\"https:\/\/twitter.com\/realcloudratics\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Auto-Harden ESXi 5.x Hosts - softwareab","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/","og_locale":"en_US","og_type":"article","og_title":"Auto-Harden ESXi 5.x Hosts - softwareab","og_description":"To run an ESXi 5.x host in a secure network requires the system to be compliant to all Information Assurance (IA) requirements. This article describes in detail how an automated hardening process was created to meet Defense Information Systems Agency &hellip; Auto-Harden ESXi 5.x Hosts Read More &raquo;","og_url":"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/","og_site_name":"softwareab","article_publisher":"https:\/\/www.facebook.com\/cloudraticsolutions\/","article_author":"https:\/\/www.facebook.com\/cloudraticsolutions\/","article_published_time":"2014-03-19T19:26:39+00:00","article_modified_time":"2014-06-04T15:57:31+00:00","author":"Andrew Bruce","twitter_card":"summary_large_image","twitter_creator":"@realcloudratics","twitter_site":"@realcloudratics","twitter_misc":{"Written by":"Andrew Bruce","Est. reading time":"36 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/#article","isPartOf":{"@id":"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/"},"author":{"name":"Andrew Bruce","@id":"https:\/\/www.softwareab.net\/wordpress\/#\/schema\/person\/1337443eaeb75104e0410b508e67f600"},"headline":"Auto-Harden ESXi 5.x Hosts","datePublished":"2014-03-19T19:26:39+00:00","dateModified":"2014-06-04T15:57:31+00:00","mainEntityOfPage":{"@id":"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/"},"wordCount":5586,"commentCount":51,"publisher":{"@id":"https:\/\/www.softwareab.net\/wordpress\/#\/schema\/person\/1337443eaeb75104e0410b508e67f600"},"keywords":["dod","ia","scripting","sysadmin","vmware"],"articleSection":["Information Assurance","Teknocratica","VMware"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/","url":"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/","name":"Auto-Harden ESXi 5.x Hosts - softwareab","isPartOf":{"@id":"https:\/\/www.softwareab.net\/wordpress\/#website"},"datePublished":"2014-03-19T19:26:39+00:00","dateModified":"2014-06-04T15:57:31+00:00","breadcrumb":{"@id":"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.softwareab.net\/wordpress\/auto-harden-esxi-5-x-hosts\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.softwareab.net\/wordpress\/"},{"@type":"ListItem","position":2,"name":"dod","item":"https:\/\/www.softwareab.net\/wordpress\/tag\/dod\/"},{"@type":"ListItem","position":3,"name":"Auto-Harden ESXi 5.x Hosts"}]},{"@type":"WebSite","@id":"https:\/\/www.softwareab.net\/wordpress\/#website","url":"https:\/\/www.softwareab.net\/wordpress\/","name":"softwareab","description":"Technocratica, Technopolitik, Technophobia","publisher":{"@id":"https:\/\/www.softwareab.net\/wordpress\/#\/schema\/person\/1337443eaeb75104e0410b508e67f600"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.softwareab.net\/wordpress\/?s={search_term_string}"},"query-input":"required name=search_term_string"}],"inLanguage":"en-US"},{"@type":["Person","Organization"],"@id":"https:\/\/www.softwareab.net\/wordpress\/#\/schema\/person\/1337443eaeb75104e0410b508e67f600","name":"Andrew Bruce","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.softwareab.net\/wordpress\/#\/schema\/person\/image\/","url":"https:\/\/www.softwareab.net\/wordpress\/wp-content\/uploads\/2024\/03\/andy-cartoon.jpg","contentUrl":"https:\/\/www.softwareab.net\/wordpress\/wp-content\/uploads\/2024\/03\/andy-cartoon.jpg","width":400,"height":330,"caption":"Andrew Bruce"},"logo":{"@id":"https:\/\/www.softwareab.net\/wordpress\/#\/schema\/person\/image\/"},"description":"Team-oriented systems mentor with deep knowledge of numerous software methodologies, technologies, languages, and operating systems. Excited about turning emerging technology into working production-ready systems. Focused on moving software teams to a higher level of world-class application development. Specialties:Software analysis and development...Product management through the entire lifecycle...Discrete product integration specialist!","sameAs":["http:\/\/cloudraticsolutions.net\/","https:\/\/www.facebook.com\/cloudraticsolutions\/","https:\/\/twitter.com\/realcloudratics"]}]}},"_links":{"self":[{"href":"https:\/\/www.softwareab.net\/wordpress\/wp-json\/wp\/v2\/posts\/675"}],"collection":[{"href":"https:\/\/www.softwareab.net\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.softwareab.net\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.softwareab.net\/wordpress\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.softwareab.net\/wordpress\/wp-json\/wp\/v2\/comments?post=675"}],"version-history":[{"count":19,"href":"https:\/\/www.softwareab.net\/wordpress\/wp-json\/wp\/v2\/posts\/675\/revisions"}],"predecessor-version":[{"id":801,"href":"https:\/\/www.softwareab.net\/wordpress\/wp-json\/wp\/v2\/posts\/675\/revisions\/801"}],"wp:attachment":[{"href":"https:\/\/www.softwareab.net\/wordpress\/wp-json\/wp\/v2\/media?parent=675"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.softwareab.net\/wordpress\/wp-json\/wp\/v2\/categories?post=675"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.softwareab.net\/wordpress\/wp-json\/wp\/v2\/tags?post=675"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}