Nému Hardened Computing

Amazon AMI Frequently Asked Questions

We are transitioning our support information to our new  Nému Help Center, please be sure to bookmark the new page.

How do I use the Nému Hardened AMIs?

Our AMIs are designed to be used in any of the standard ways you use Amazon AWS. Use it in a CloudFormation template to build rapid deployment solutions for your Federal customers. Use it with the AWS CLI to create machines easily. Or manually create instances using the AWS Console.


Why does the AMI come with four EBS volumes?

To ensure compliance with CIS and STIG regulations, we have separated /var, /var/log/audit, and /home out to separate EBS volumes, and have configured /tmp and /var/tmp to be in-memory tmpfs filesystems. You are expected to size these volumes out to fit your specific needs when you create EC2 instances from this AMI. And we assume that your project doesn't have any long-term storage needs in /tmp or /var/tmp. Files kept there will go away on system reboot.


How can I resize the EBS volumes to fit my project's needs?

When using CloudFormation or the Amazon CLI, please use the following JSON to specify volume sizes and encryption options on your new EC2 instance:


"ec2-instance": {
    "Type": "AWS::EC2::Instance",
    "Properties": {
      "ImageId": "ami-xxxxxxxxx",
      "InstanceType": "t2.small",
      "KeyName": "my-ec2-keypair",
      "BlockDeviceMappings": [
	    { "DeviceName": "/dev/sda1",
		  "Ebs": {
		          "DeleteOnTermination":"true",
		          "VolumeType":"gp2",
		          "VolumeSize":"100"
		  }
		},
		{ "DeviceName": "/dev/xvdl",
		  "Ebs": {
		          "DeleteOnTermination":"true",
		          "VolumeType":"gp2",
		          "VolumeSize":"10"
		  }
		},
		{ "DeviceName": "/dev/xvdh",
		  "Ebs": {
		          "DeleteOnTermination":"true",
		          "VolumeType":"gp2",
		          "VolumeSize":"2"
		  }
		},
		{ "DeviceName": "/dev/xvdx",
		  "Ebs": {
		            "DeleteOnTermination":"true",
		            "VolumeType":"gp2",
		            "VolumeSize":"2"
		  }
		},
	  ]
	}
}


If you are creating EC2 instances from the Amazon console, override the default volume sizes on Page 4 of the Launch Instance wizard.


(If you prefer an EC2 instance with a single root volume, please e-mail [email protected] and let us know. We're happy to accommodate!)


Can I launch an EC2 instance with encrypted volumes?

Yes! Either select the encryption keys you want to use under the Encryption column of the Storage page when launching a new instance (see the screenshot above), or specify the encryption key in your CloudFormation template by setting the Encrypted property to "true" under the BlockDeviceMappings of your EC2 instance. (This seems to be a new EC2 feature, please let us know if you encounter any problems using it!)


What type of EC2 instance should I select?

While we enable you to launch our products in essentially any instance size you desire, the smaller sizes (t2.nano through t2.small) will most likely not suit your application's needs. Please refer to Amazon's EC2 Instance Types guide to select an instance type that meets your CPU, Memory, and network latency needs when building your application.


How do I update my EC2 instance to the latest STIG baseline?

At present, the easiest way to ensure your EC2 instances can be updated to the latest quarterly STIG releases is to create them using a CloudFormation (or similar) automated build system, specifying the baseline AMI ID as a parameter in the build process. As long as your system can be automatically rebuilt, updating the stack parameter (using CloudFormation as an example) would automatically build new servers with the latest STIG baselines, join them to the Elastic Load Balancer, and drop the old servers when that is done.

But not everybody is Netflix, and this level of automation is very hard to achieve with many applications.

We're looking at offering a continual upgrade program, that will allow our AWS Marketplace customers a way to use our on-premise Nému Hardened Computing client software to apply the latest baselines to their running EC2 instances.

We're not sure how much of a demand there is for this yet - so if this is something that's important to you, please don't hesitate to let us know.


How can I use yum? The system is giving me errors!

Under STIG guidelines, Yum on RedHat is configured to examine GPG signatures on all packages that are installed on the system.  Unfortunately, Amazon does not (and refuses to) sign any of the packages that they make available on their RedHat mirror servers.  As a result, when you try running "yum update" (or any other yum operation) on your system, you end up getting an error like this:

[ec2-user@hostname ~]$ sudo yum update -y
Loaded plugins: amazon-id, search-disabled-repos
https://rhui3.us-east-1.aws.ce.redhat.com/pulp/repos/content/dist/rhel/rhui/server/7/7Server/x86_64/rh-common/os/repodat
a/repomd.xml.asc: [Errno 14] HTTPS Error 404 - Not Found
Trying other mirror.
...
rhel-7-server-rhui-rh-common-rpms                                                                | 2.1 kB  00:00:00     
...
failure: repodata/repomd.xml.asc from rhel-7-server-rhui-rh-common-rpms: [Errno 256] No more mirrors to try.
https://rhui3.us-east-1.aws.ce.redhat.com/pulp/repos/content/dist/rhel/rhui/server/7/7Server/x86_64/rh-common/os/repodata/repomd.xml.asc:
                 [Errno 14] HTTPS Error 404 - Not Found 

The workaround is, thankfully, simple.  But it's technically a violation of STIG guidelines.  So you'll have to use your own judgement to determine the risk profile of using this workaround. (The only STIG-compliant workaround is running your own RedHat Satellite service, with all of the licensing and server management issues that are involved with doing that.)

As long as you accept that Amazon's RedHat deployment infrastructure is secure enough that this is a low-risk operation (as we do), you can get around this by adding --nogpgcheck to your yum commands:

[ec2-user@ip-172-31-51-171 ~]$ sudo yum --nogpgcheck update -y
Loaded plugins: amazon-id, search-disabled-repos
rhel-7-server-rhui-rh-common-rpms                                                                | 2.1 kB  00:00:00     
rhel-7-server-rhui-rpms                                                                          | 2.0 kB  00:00:00     
rhui-client-config-server-7                                                                      | 2.1 kB  00:00:00     
(1/9): rhel-7-server-rhui-rh-common-rpms/7Server/x86_64/group                                    |  124 B  00:00:00     
(2/9): rhel-7-server-rhui-rh-common-rpms/7Server/x86_64/updateinfo                               |  33 kB  00:00:00     
(3/9): rhel-7-server-rhui-rh-common-rpms/7Server/x86_64/primary                                  |  65 kB  00:00:00     
(4/9): rhel-7-server-rhui-rpms/7Server/x86_64/group                                              | 772 kB  00:00:00     
(5/9): rhel-7-server-rhui-rpms/7Server/x86_64/updateinfo                                         | 3.5 MB  00:00:00     
(6/9): rhui-client-config-server-7/x86_64/group                                                  |  124 B  00:00:00     
(7/9): rhui-client-config-server-7/x86_64/updateinfo                                             |   92 B  00:00:00     
(8/9): rhui-client-config-server-7/x86_64/primary                                                | 1.3 kB  00:00:00     
(9/9): rhel-7-server-rhui-rpms/7Server/x86_64/primary                                            |  39 MB  00:00:01     
rhel-7-server-rhui-rh-common-rpms                                                                               239/239
rhel-7-server-rhui-rpms                                                                                     26517/26517
rhui-client-config-server-7                                                                                         3/3
No packages marked for update


Can I clone these AMIs?

No.

You are prohibited under the terms of our End User License Agreement from creating any cloned instances of our AMI for use in your internal provisioning process. If you require this functionality in order to provide customized instances based on our AMI for your internal use, please contact our sales team for licensing. All licensing is based on the total number of EC2 instances that will be running during a 12 month period using any of our AMI baselines as a starting point.


How are the Apache Hardened Tomcat AMIs configured?

Our Apache Hardened Tomcat AMIs are built on our DISA STIG Hardened RedHat images, to provide a secure baseline for the application server stack. Because the DISA Application Server SRG is somewhat generic in scope, and many of the controls listed within it are specific to your application code, the final bit of hardening will depend on how you configure your application. We've covered the basics, though:

  • Tomcat is configured to listen with a self-signed SSL certificate on port 8443,
  • We've disabled the Server banner, both at the HTTP header level, and in the Tomcat error pages,
  • and the SSL listener is configured to be restricted to DOD-approved encryption algorithms.

This should be more than enough to get you well down the road to running a fully compliant web application!  But if you think you need more, please don't hesitate to let us know.


What's the best way to use the Tomcat AMIs?

We recommend deploying these AMIs in a CloudFormation stack, using a user-data script to push your .war files out to the /opt/tomcat/webapps folder automatically as the system is built.

If you are running multiple Tomcat servers to achieve optimum high availability, we recommend configuring an Elastic Load Balancer in front of the Tomcat instances. The frontend of the ELB will be configured to listen on port 443 with your actual SSL certificate, and the backend can either run over https/8443 (if your application requires full encryption between all layers), or http/8080 if your ISSO trusts the ELB->EC2 network.

If you are running only a single Tomcat instance, we still recommend running behind an ELB for enhanced security. But you can also run the product standalone - No reconfiguration of Tomcat is needed. Just run the following commands to enable incoming traffic on the standard HTTP and HTTPS ports:

## HTTPS
sudo firewalld --add-service=https
sudo firewalld --add-service=https --permanent
sudo firewalld --add-forward-port=port=443:proto=tcp:toport=8443
sudo firewalld --add-forward-port=port=443:proto=tcp:toport=8443 --permanent

## HTTP
sudo firewalld --add-service=http
sudo firewalld --add-service=http --permanent
sudo firewalld --add-forward-port=port=80:proto=tcp:toport=8080
sudo firewalld --add-forward-port=port=80:proto=tcp:toport=8080 --permanent

You'll also need to deploy your own SSL certificate into the /opt/apache/conf/localhost-rsa.jks file, and add the desired ports to your AWS Security Groups.

We also have a prebuilt RDS + Tomcat + ELB CloudFormation template available if you want to set up a highly available Tomcat application with almost zero effort. Let us know if you want a copy!


How can I deploy application code to the Apache Tomcat AMIs?

The best way to deploy software to a Tomcat instance (not just ours!) on Amazon AWS is with an EC2 UserData script.

The following script will deploy your application to a subdirectory ("mysystem.com/application/") on your Tomcat server. Nému Hardened Tomcat comes with a simple DOD Warning and Consent banner that it will prompt the user to accept for before sending them to your application.

#!/bin/sh    
logger "Starting user-data deployment script"    
WAR_URL="https://s3.amazonaws.com/your-bucket-name/application.war"      
[ "x${WAR_URL}" = x ] &&    
        logger "No WAR file provided to instance" &&
exit      
WAR_FILENAME=`basename ${WAR_URL}`    
WAR_DIRNAME=`echo ${WAR_FILENAME} | sed 's/\.[Ww][Aa][Rr]$//g'`    
logger "Starting deployment: ${WAR_URL} -> /opt/tomcat/webapps/${WAR_DIRNAME}"    
curl -o /opt/tomcat/webapps/"${WAR_FILENAME}" "${WAR_URL}" &&
        mkdir -p /opt/tomcat/webapps/"${WAR_DIRNAME}" &&
        cd /opt/tomcat/webapps/"${WAR_DIRNAME}" &&
        unzip /opt/tomcat/webapps/"${WAR_FILENAME}" &&
        rm -f /opt/tomcat/webapps/"${WAR_FILENAME}" &&
        echo "/${WAR_DIRNAME}/" > /opt/tomcat/webapps/ROOT/application.url
chown -R tomcat:tomcat /opt/tomcat/webapps    
find /opt/tomcat/webapps -type f -exec chmod a+r {} \;    
find /opt/tomcat/webapps -type d -exec chmod a+rx {} \;    
rm -f "/opt/tomcat/webapps/${WAR_FILENAME}"    
chmod a+x /opt/tomcat    
restorecon -rv /opt/tomcat    
systemctl restart tomcat    
logger "Deployed application ${WAR_DIRNAME} to tomcat from: ${WAR_URL}"


If your application needs to live in the root URL ("mysystem.com/"), use this script instead. Note that your application will need to provide a DOD Warning and Consent banner of its own.

#!/bin/sh    
logger "Starting user-data deployment script"    
WAR_URL="https://s3.amazonaws.com/your-bucket-name/application.war"      
[ "x${WAR_URL}" = x ] &&    
        logger "No WAR file provided to instance" &&
exit      
WAR_FILENAME=`basename ${WAR_URL}`    
WAR_DIRNAME="ROOT"
logger "Starting deployment: ${WAR_URL} -> /opt/tomcat/webapps/${WAR_DIRNAME}"    
curl -o /opt/tomcat/webapps/"${WAR_FILENAME}" "${WAR_URL}" &&
        mkdir -p /opt/tomcat/webapps/"${WAR_DIRNAME}" &&
        cd /opt/tomcat/webapps/"${WAR_DIRNAME}" &&
        unzip /opt/tomcat/webapps/"${WAR_FILENAME}" &&
        rm -f /opt/tomcat/webapps/"${WAR_FILENAME}"
chown -R tomcat:tomcat /opt/tomcat/webapps    
find /opt/tomcat/webapps -type f -exec chmod a+r {} \;    
find /opt/tomcat/webapps -type d -exec chmod a+rx {} \;    
rm -f "/opt/tomcat/webapps/${WAR_FILENAME}"    
chmod a+x /opt/tomcat    
restorecon -rv /opt/tomcat    
systemctl restart tomcat    
logger "Deployed application ${WAR_DIRNAME} to tomcat from: ${WAR_URL}"


For a more complex application with multiple WAR files, simple modifications to the scripts above should be all it takes to get started. But if you have trouble trying to get it to work, our Support Team is standing by to help!


How can I use a different JDK with the Apache Tomcat AMIs?

If your application requires a different JDK than what we provide with the Apache Tomcat AMIs (Oracle JDK, IBM JDK, different JDK version), you can take the following steps to reconfigure Tomcat. (Please make sure the JDK you intend to use is supported by Tomcat.)

If you are able to use OpenJDK:

  1. Login to the instance
  2. Stop the Tomcat service by running:
    sudo systemctl stop tomcat
  3. Remove the existing OpenJDK packages by running:
    yum remove -y java-1.8.0-openjdk-headless
  4. Install the desired OpenJDK packages by running the command associated with the JDK version you need:
    yum install -y java-1.7.0-openjdk-headless
    yum install -y java-1.8.0-openjdk-headless
    yum install -y java-11-openjdk-headless
    (If you prefer the full JDK, remove "-headless" from the commands above)
  5. Start the Tomcat service by running:
    sudo systemctl start tomcat
  6. Test your instance to ensure it is still operating as expected.
  7. If confirmed to be working, these steps can be incorporated into a user-data script to automate this process.

If you require Oracle or IBM JDK:

Due to licensing restrictions, we cannot ship Oracle or IBM products with our AMIs. If you are licensed to use these products, you can deploy them to our AMIs using the following steps:

  1. Download the JDK from your vendor
  2. Copy the JDK to your EC2 instance
  3. Stop the Tomcat service by running:
    systemctl stop tomcat
  4. Remove the existing OpenJDK packages by running:
    yum remove -y java-1.8.0-openjdk-headless
  5. Install your JDK into the directory you desire. Using Oracle as an example:
    cd /opt
    tar xzf jdk-8u221-linux.tar.gz
    # Package installed into /opt/jdk-1.8.0_221
  6. Edit the /usr/lib/systemd/system/tomcat.service file and modify the highlighted lines to point to your JDK:
    [Service]
User=tomcat
WorkingDirectory=/opt/tomcat
Environment=JRE_HOME=/opt/jdk-1.8.0_221/jre
Environment=JAVA_HOME=/opt/jdk-1.8.0_221/jre
Environment=CATALINA_HOME=/opt/tomcat
Environment=CATALINE_BASE=/opt/tomcat
  7. Start the Tomcat service by running:
    systemctl start tomcat
  8. If Tomcat fails to start, examine the /var/log/tomcat/catalina.out file for error messages.
  9. If confirmed to be working, these steps can be incorporated into a user-data script (using an S3 bucket to store your JDK package) to automate this process.



Why does RHEL V-71949 keep failing my scans?

Because Amazon does not set a password on Linux images, and requires users to use an SSH key to authenticate to deployed instances, we can NOT enable password-based re-authentication for Sudo sessions out of the box. You can, however, enable this on your own by following these steps:

  1. Set a password for the ec2-user account. It is recommended to use the passwd command as ec2-user, to ensure password expiration rules are enforced.
  2. Run the command "sudo su -" to become root.
  3. Run "sudoedit" to edit the /etc/sudoers file.
  4. Find the lines that contain "NOPASSWD: ALL" within this file
  5. Remove the keyword "NOPASSWD" and the trailing colon
  6. Save the file (the vi command "ZZ" will do this)
  7. DO NOT LEAVE YOUR ROOT SESSION.
  8. Open a new terminal window, and login to your server as ec2-user
  9. Try running "sudo su -"
  10. Confirm that you are prompted for your password.

Once these steps are completed, your system will be compliant with V-71949.


Why are the audisp-remote controls failing?

There is no way for us to configure remote auditing in your environment without knowing where audit logs will be sent to.  So until our Nému Scribe product is available to solve that problem for you, please refer to your operating system's documentation on the correct steps to set this up.


What kind of support is included?

All subscriptions include support for the duration of your subscription, in order to ensure our products function as intended. It should be noted that hardened operating systems commonly require special configuration in many third-party software products. We are happy to help you resolve any integration issues you find only to the scope that our team is able to assist. We're your operating system experts, but you're your application experts.

If you encounter a defect in any of our products - Say, for instance, our competitor's scanner says it's vulnerable! - we will investigate and fix our products as necessary. This level of support is available for all active and prospective customers. We stand behind our work, 100% of the time!

(Any issues that are reported will be shared with customers immediately on our Release Notes page.)

All support inquiries should be directed to [email protected], or via voicemail at (505) NEMU123


What if I can't buy through the Marketplace?

In the event that your Federal organization does not allow subscription to Marketplace AMIs, we can share our baseline images with your account directly. Please click on the Shop link at the top of the screen to view available products.


Do you support Microsoft Windows?

We have released our Hardened Windows Server 2016 and Windows Server 2019 in AWS Marketplace.  Other releases of Windows can be made available upon request.  And if you have any issues, we'll be around to help you out!


...Anything else?

If you have any questions that we did not answer here, please contact us at [email protected].

(We do have other products on the way. Please don't be shy if there's something you are looking for!)


Please check on our Release Notes page for the latest updates, including issues found with our product line. We stand by what we build and work as hard as we can to ensure you are getting the highest quality value for your purchase!