Archive for the ‘Security’ Category

Rebooting: quick tip

Wednesday, April 9th, 2014

Note to self: whenever rebooting a server, login via SSH and restart the OpenSSH daemon first to validate that it will come back up.

I just updated an AWS instance and rebooted it without doing this. Some new update in OpenSSH required that the AuthorizedKeysCommandUser be defined if AuthorizedKeysCommand is defined and the OpenSSH daemon will not start.

Luckily I can tell puppet to fix this and will be able to login in 30 minutes but that’s 30 minutes I’d prefer not to wait.

- josh

AWS VPC DB Security Group

Tuesday, December 18th, 2012

The other day I was working with a client and creating a CloudFormation template that used RDS instances within a VPC. I found that while creating the DB security group object that I was getting an error like the following:

STACK_EVENT  CloudFormationName  DBSecurityGroupName   
       AWS::RDS::DBSecurityGroup                2012-12-17T22:30:20Z  CREATE_FAILED
       Please see the documentation for authorizing DBSecurityGroup ingress. For VPC,
       EC2SecurityGroupName and EC2SecurityGroupOwner must be omitted.To 
       authorize only the source address of this request (and no other address), pass
       xx.xx.xx.xx/32 as the CIDRIP parameter.

It turns out that beyond the requirement for a DB subnet group, I also needed to change the way that I create DB security groups within the VPC. I solved this problem by using the CIDRIP parameter and included the IP ranges of two private subnets:

    "DBSecurityGroupName": {
       "Type": "AWS::RDS::DBSecurityGroup",
       "Properties": {
          "EC2VpcId" : { "Ref" : "VpcName" },
          "DBSecurityGroupIngress" : [ { "CIDRIP": "10.1.201.0/24" }, { "CIDRIP": "10.1.301.0/24" } ],
          "GroupDescription": "Application Server Access"
        }   
    },

The examples given on the official docs page did not help with this issue, I found that I was experimenting until I was able to get this working. I copied the examples and they failed for this particular scenario.

SSH Public Key Authentication via OpenLDAP on RHEL/CentOS 6.x

Tuesday, September 4th, 2012

With the release of RHEL/CentOS 6.x there are some changes to the way clients authenticate using public keys over SSH with keys stored in OpenLDAP. I was able to get this working with the following modifications.

Pre-requisites:
* RHEL / CentOS 6.x
* openssh-ldap

Setup the sshd_config by setting up the AuthorizedKeysCommand. This will execute the ssh-ldap-wrapper and output the users public key:

AuthorizedKeysCommand /usr/libexec/openssh/ssh-ldap-wrapper

Next, ensure a proper ldap.conf in /etc/ssh — be sure to setup the appropriate level of TLS security to suite your environment:

ldap_version 3
bind_policy soft

binddn cn=readonly,ou=people,dc=example,dc=com
bindpw secret

ssl no
ssl start_tls
tls_reqcert never
tls_cacertdir /etc/openldap/cacerts

host 10.x.x.x
port 389
base dc=example,dc=com

If the LDAP server is setup with the proper schema and contains public keys, this configuration should work.

For more information on how to setup the schema and insert public keys, review the documents here but be sure to note that things have changed with client configuration.

DNS Vulnerability

Wednesday, July 9th, 2008

Tuesday a vulnerability was made public which affects all users of the DNS system. The vulnerability was discovered by Dan Kaminsky, a prominent researcher in the area of DNS, who organized a mass patch release by major vendors to prevent delays between the vulnerability becoming public and the patch being released.

http://doxpara.com/

This is a critical fix that should be applied ASAP to all DNS servers, regardless of vendor.