No SSD drives in us-east-1b, looks like a constrained zone issue again

For instances started in us-east-1b, we cannot choose SSD volumes for disk:

Surprising that m3 instance type is not available in a constrained zone us-east-1b

In region, there is a constrained zone (which can vary per AWS a/c) and some of the instances types are not available. In this particular case, us-east-1b does not have even m3 type instances:-

Looks like m1.xlarge instance types are no-longer available in us-east-1c zone

It appears that Amazon have started phasing out some of the first generation machines from some of zones in the older regions like us-east-1c. If you try to launch a first generation machine like m1.xlarge, you will see a launch error like below:-

Creating an IAM user policy to restrict user to add only ingress ports

The AWS CLI is not the most intuitive in terms of mandatory switches that it needs. To make matters worse, the IAM policy simulator is rudimentary in terms of functionally checking the policies. Recently, I had to enable a user to allow adding ingress rules to a particular security group in a vpc, the user policy looked like

*************
{
"Version": "2012-10-17",
  "Statement":[{
    "Effect":"Allow",
    "Action": [
       "ec2:AuthorizeSecurityGroupIngress",
       ],
     "Resource": "arn:aws:ec2:<region>:<aws_account>:security-group/<sg-group-name>",
        "Condition": {
        "StringEquals": {
          "ec2:Vpc": "arn:aws:ec2:<region>:<aws_account>:vpc/<vpc-id>"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "ec2:DescribeSecurityGroups",
      "Resource": "*"
    }
  ]
}
*************

The above policy passed in the IAM policy simulator just fine. However, during runtime, using the below command

*************
$aws ec2 authorize-security-group-ingress --group-name <sg-group-name> --protocol tcp --port 80 --cidr <block ip> --profile <profile-name>

A client error (InvalidGroup.NotFound) occurred when calling the AuthorizeSecurityGroupIngress operation: The security group '<sg-group-name>' does not exist in default VPC '<default-vpc-id>'
*************

Since the user policy was created with resource arn pointing to <sg-group-name>, the above was assumed to work, but it does not. As per AWS doc, it is required to give security group id instead of name

So the above policy had to be modified to include security group id:

*************
....
"Resource": "arn:aws:ec2:<region>:<aws_account>:security-group/<sg-group-id>",
....
*************

Correspondingly, the aws cli command needs to pass security group id as well:

*************
$aws ec2 authorize-security-group-ingress --group-id <sg-group-id> --protocol tcp --port 80 --cidr <block ip> --profile <profile-name>
{
    "return": "true"
}
*************

Had to spend sometime troubleshooting this subtle difference in group id and group name, whereas policy simulator or aws cli can save folks some time if this difference is made obvious.

Disable Apache and PHP signature on external facing websites

For security reasons, you will want to disable Apache and PHP signature (versions) in external facing sites. When signature is not hidden you will see headers like

*************

HTTP/1.1 200 OK

Cache-Control: no-cache

Content-Type: text/html; charset=utf-8

Date: Mon, 20 Oct 2014 19:35:43 GMT

Pragma: no-cache

Server: Apache/2.4.9 (Unix) PHP/5.5.11

X-Powered-By: PHP/5.5.11

*************

To hide the signatures, you can make the following changes in your apache's httpd.conf and php.ini file

httpd.conf

**************
ServerSignature Off
ServerTokens Prod
TraceEnable Off
**************

php.ini

**************
expose_php = Off
**************

After the above changes, you will have to restart your httpd server. 

CVE-2014-3513 - SSLv3 (poodle attack) Openssl memory leak can cause DoS attack

The new SSLv3 vulnerability found by Google researchers:-

http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

has widespread implications for the servers that are ssl termination points. For now, they have to disable SSLv3 ciphers or protocol itself. Additionally, they have to check the reverse proxies to see if strong ciphers (TLS) can only be allowed.

Amazon have also released patches for Amazon Linux and instructions for ELB:-

http://aws.amazon.com/security/security-bulletins/CVE-2014-3566-advisory/

https://alas.aws.amazon.com/index.html

****************

Amazon Linux AMI:
The Amazon Linux AMI repositories now include patches for POODLE (CVE-2014-3566) as well as for the additional OpenSSL issues (CVE-2014-3513, CVE-2014-3568, CVE-2014-3567) that were released on 2014-10-15. Please see https://alas.aws.amazon.com/ALAS-2014-426.html and https://alas.aws.amazon.com/ALAS-2014-427.html for additional information.

Amazon Elastic Load Balancing:
All load balancers created after 10/14/2014 5:00 PM PDT will use a new SSL Negotiation Policy that will by default no longer enable SSLv3.
Customers that require SSLv3 can reenable it by selecting the 2014-01 SSL Negotiation Policy or manually configuring the SSL ciphers and protocols used by the load balancer. For existing load balancers, please follow the steps below to disable SSLv3 via the ELB Management
Console:
    1. Select your load balancer (EC2 > Load Balancers).
    2. In the Listeners tab, click "Change" in the Cipher column.
    3. Ensure that the radio button for "Predefined Security Policy" is selected
    4. In the dropdown, select the "ELBSecurityPolicy-2014-10" policy.
    5. Click "Save" to apply the settings to the listener.
    6. Repeat these steps for each listener that is using HTTPS or SSL for each load balancer.

For more information, please see http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-ssl-security-policy.html.

****************************

You can also change the cipher suite policy in the ELB configuration by selecting the version "ELBSecurityPolicy-2014-10" below:-

GCE vs AWS Instance Pricing Charts

Straight out of RightScale blog link:-

On-Demand pricing comparison:-

1 yr Sustained use vs Reserved Instance pricing comparison:-

3 yr Sustained use vs Reserved Instance pricing comparison:-

Patching bash on old releases such as CentOS 5

You should be able to use the package manager to update the bash version. In some cases, if you want specific version of bash such as bash-3.2-33.el5_11.4, then you can download and instance using rpm

$wget http://mirror.centos.org/centos/5/updates/x86_64/RPMS/bash-3.2-33.el5_11.4.x86_64.rpm
$sudo rpm -ivh --force bash-3.2-33.el5_11.4.x86_64.rpm

Shellshock: Take two!.

The script mentioned in the redhat "diagnostic steps" is attached below and can be download from Redhat labs access page using login:-

*****************
#!/bin/bash
# shellshock-test.sh

VUNERABLE=false;
CVE20146271="$(env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test" 2>&1 )"

CVE20147169=$(cd /tmp 2>&1; rm -f /tmp/echo 2>&1; env 'x=() { (a)=>\' bash -c "echo uname" 2>&1; cat /tmp/echo 2>&1; rm -f /tmp/echo 2>&1 )

if [[ "$CVE20146271" =~ "vulnerable" ]]
then
    echo "This system is vulnerable to CVE-2014-6271 <https://access.redhat.com/security/cve/CVE-2014-6271>"
    VUNERABLE=true;
elif [[ "$CVE20146271" =~ "bash: error importing function definition for 'x'" ]]
then
    echo "This system does not have to most up to date fix for CVE-2014-6271 <https://access.redhat.com/security/cve/CVE-2014-6271>.  Please refer to 'https://access.redhat.com/articles/1200223' for more information"
else
echo "This system is safe from CVE-2014-6271 <https://access.redhat.com/security/cve/CVE-2014-6271>"
fi

if [[ "$CVE20147169" =~ "Linux" ]]
then
    echo "This system is vulnerable to CVE-2014-7169 <https://access.redhat.com/security/cve/CVE-2014-7169>"
    VUNERABLE=true;
else
echo "This system is safe from CVE-2014-7169 <https://access.redhat.com/security/cve/CVE-2014-7169>"
fi

if [[ "$VUNERABLE" = true ]]
then
echo "Please run 'yum update bash'.  If you are using satellite or custom repos you need to update the channel with the latest bash version first before running 'yum update bash'.  Please refer to 'https://access.redhat.com/articles/1200223' for more information"
fi

*****************

just save the above file and give +x permission on the script.

Problems with s3cmd utility

On one of the cloud instances, I was trying to upload a large file to a S3 bucket and I had to install s3cmd utility. Going with the approach of getting the latest and greatest did not serve well. I downloaded the 1.5.0 rc1 version from the link - s3cmd and unzipped it into a folder. Subsequently, I ran the install command from the installation director

$ sudo python setup.py install

the above seemed to work fine. However, when I tried to run "s3cmd --configure", I got the below error:-

***********

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

    An unexpected error has occurred.

  Please try reproducing the error using

  the latest s3cmd code from the git master

  branch found at:

    https://github.com/s3tools/s3cmd

  If the error persists, please report the

  following lines (removing any private

  info as necessary) to:

   s3tools-bugs@lists.sourceforge.net

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Traceback (most recent call last):

  File "/usr/bin/s3cmd", line 2527, in <module>

    report_exception(e)

  File "/usr/bin/s3cmd", line 2465, in report_exception

    s = u' '.join([unicodise(a) for a in sys.argv])

NameError: global name 'unicodise' is not defined

***********

On their github, it appears that other have run into the issue without a proper resolution. So later had to go back to the option of installing through package manager on RHEL instance to make it work.

$cd /etc/yum.repos.d/

$wget http://s3tools.org/repo/RHEL_6/s3tools.repo

$sudo yum install s3cmd

$s3cmd --configure

All 6 CVE's of bash "shellshock" vulnerabilities now seem to have been addressed

Pl. refer to Redhat article - link

Diagnostic Steps

Red Hat Access Labs has provided a script to help confirm if a system is patched against to the Shellshock vulnerability. You can also manually test your version of Bash by running the following command:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"

If the output of the above command contains a line containing only the word vulnerable you are using a vulnerable version of Bash. The patch used to fix this issue ensures that no code is allowed after the end of a Bash function.

Note that different Bash versions will also print different warnings while executing the above command. The Bash versions without any fix produce the following output:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
vulnerable
bash: BASH_FUNC_x(): line 0: syntax error near unexpected token `)'
bash: BASH_FUNC_x(): line 0: `BASH_FUNC_x() () { :;}; echo vulnerable'
bash: error importing function definition for `BASH_FUNC_x'
test

The versions with only the original CVE-2014-6271 fix applied produce the following output:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
bash: error importing function definition for `BASH_FUNC_x()'
test

The versions with additional fixes from RHSA-2014:1306, RHSA-2014:1311 and RHSA-2014:1312 produce the following output:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `BASH_FUNC_x'
test

The difference in the output is caused by additional function processing changes explained in the "How does this impact systems" section below.

The fix for CVE-2014-7169 ensures that the system is protected from the file creation issue. To test if your version of Bash is vulnerable to CVE-2014-7169, run the following command:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
Fri Sep 26 11:49:58 GMT 2014

If your system is vulnerable, the time and date information will be output on the screen and a file called /tmp/echo will be created.

If your system is not vulnerable, you will see output similar to:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
date
cat: /tmp/echo: No such file or directory

If your system is vulnerable, you can fix these issues by updating to the most recent version of the Bash package by running the following command:

# yum update bash