Thursday, October 30, 2014
Monday, October 27, 2014
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.
*************
{
"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.
Monday, October 20, 2014
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
*************
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.
*************
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.
Thursday, October 16, 2014
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
****************
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.
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.
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:-
Wednesday, October 8, 2014
GCE vs AWS Instance Pricing Charts
Straight out of RightScale blog link:-
On-Demand pricing comparison:-
On-Demand pricing comparison:-
1 yr Sustained use vs Reserved Instance pricing comparison:-
3 yr Sustained use vs Reserved Instance pricing comparison:-
Wednesday, October 1, 2014
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
$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.
*****************
#!/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:-
***********
$ 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:
If the error persists, please report the
following lines (removing any private
info as necessary) to:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!
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
Subscribe to:
Posts (Atom)