Wednesday, March 4, 2015

How to check for SSL FREAK Vulnerability?

A research group named SMACK has released a vulnerability known as FREAK which can be used for man-in-the-middle (MITM) attack. The vulnerability is due to an old ghost created by USA Government (NSA, more specifically) where in, years ago, they convinced several organizations to use weaker keys, known as export-grade keys for any software that was to be used outside the borders of USA. While the use of strong keys is wide spread now, several servers still have support for the weaker keys.

The group discovered that this vulnerability can be exploited by using a client and making a connection via a weak key. Once the key is generated by the server, it is reused until the server is restarted which can potentially be months. The group was able to crack this weak server key in 7.5 hours using Amazon EC2. Once this is cracked, potentially all the communication can be downgraded to use weak keys and MITM'ed.

How to check if a server vulnerable or not?
Fire the following command:
$ openssl s_client -connect -cipher EXPORT

A handshake failure signifies that EXPORT cipher is not active on the server and it is safe.

Hacker News: Discuss and upvote on Hacker News.

Monday, January 5, 2015

Basic Docker Orchestration with Google Kubernetes on Fedora

Kubernetes is new framework by Google to manage Linux container clusters. I started playing with it today and it seems like a cool, powerful tool to manage a huge barrage of containers and to ensure that a predefined number of containers are always running. Installation and configuration on Fedora and many other distributions can be found at these Getting Started Guides. I recommend using two machines for this experiment (one physical and one VM is fine). Kubelet (or Minion) is the one where Docker containers will run, so use more powerful machine for that.

After the installation we'll see something like below when we look for minions from kube master:
master# kubectl get minions
NAME                LABELS
fed-minion          <none>

Now we would move to Kubernetes 101 Walkthrough where we will run a container using the yaml from the Intro section.
master# kubectl create -f kubeintro.yaml

.. except, (as on 25 Dec 2014) it won't run. It will give an error like this:
the provided version "v1beta1" and kind "" cannot be mapped to a supported object

Turns out that a field "kind" is empty. So the kubectl won't be able to run the container. Correct this so that kubeintro looks like this:

master# cat kubeintro.yaml
apiVersion: v1beta1
kind: Pod
id: www
  replicas: 2
    version: v1beta1
    id: www
      - name: nginx
        image: dockerfile/nginx

Optional: Now, I do not exactly know what is there inside the image "dockerfile/nginx". So I would replace it with something that I want to spawn like "adimania/flask" image. The dockerfile for my flask image can be found in Fedora-Dockerfiles repo.

Once the kubeintro.yaml is fixed, we can run it on the master and we'll see that a container is started on the minion. We can stop the container on the minion using docker stop command and we'll see the kubernetes will start the container again.

The example above doesn't do much. We need to publish the ports of the container so that we can access the webpage served by it. Modify the kubeintro.yml to tell it to publish ports like this:

master# cat kubeintro.yaml
apiVersion: v1beta1
kind: Pod
id: www
  replicas: 2
    version: v1beta1
    id: www
      - name: nginx
        image: dockerfile/nginx
          - containerPort: 80
            hostPort: 8080

Now delete the older pod named www and start a new one from the new kubeintro.yaml file.
master# kubectl delete pod www
master# kubectl create -f kubeintro.yaml

We can browse via a browser to localhost:8080 and we'll see Nginx serving the default page. (If we would have used "adimania/flask" image, we would have seen "Hello from Fedora!" instead.)

Sunday, December 7, 2014

Docker Quick Start Guide

Here is a short and sweet guide to Docker for absolute beginners. I have added a few FAQs as well.

Q. What is a container?
A. Container is an isolated Linux system running on a Linux machine itself. They are lightweight and consume less resources than a virtual machine. They rely on kernels cgroups and namespace features to create isolation for CPU, memory etc..

Q. What is Docker?
A. Docker is a container based platform to build and ship applications. Docker makes containers easy to use by providing a lot of automation and tools for container management.

Q. Why would I use Docker?
A. If you have any of the following concerns then you should use Docker:
  • My production needs to be homogeneous
  • I need to ship entire environment to my colleague
  • My hypervisor ate all the CPU (or RAM)
  • .. it works on my machine, but not in production  ..

How to play with Docker
Step1: Let us install and run the Docker first:
# yum install docker-io
# systemctl start docker

Step2: Docker has something called registries. A registry stores container images from which we can download and run containers. These registries can be public or private. maintains a public registry which is the default if we want to download an image. The command below will download an image with name fedora-busybox, contributed by user adimania:
# docker pull adimania/fedora-busybox
Pulling repository adimania/fedora-busybox
605bfcc0af5d: Download complete

Step3: Let us check out the image that we just downloaded.
# docker images
REPOSITORY                   TAG                 IMAGE ID            CREATED             VIRTUAL SIZE

adimania/fedora-busybox      latest              605bfcc0af5d        7 minutes ago        1.309 MB

Step4: Once we have the image, we would want to run a container off it. The command below will take care of that and drop us in the container's shell:
# docker run -i -t adimania/fedora-busybox /sbin/sh

The run command takes certain parameters and run the image provided as argument. The arguments "-i" and "-t" tells run command to open STDIN and allocate a pseudo-TTY. Last argument is the command that is runs inside the container in foreground. One thing to note here is that docker always need a process to run in foreground. As soon as this process exits, the docker container shuts down. For certain containers, this foreground process is implicit and we may not need to tell docker what to run. However for certain other containers, like the one which we are using, we specify "/sbin/sh" to run as foreground process. docker run command supports several other arguments and flags. It is advisable to fire docker run --help to check out all the options.

Step5: We can see more information about this containers that are currently running by using docker ps command:
# docker ps
CONTAINER ID    IMAGE                      COMMAND          CREATED             STATUS              PORTS            NAMES
3af04d663b3d      adimania/fedora-busybox:latest   "/sbin/sh"         25 seconds ago      Up 24 seconds          furious_leakey

docker ps commands shows all the containers that are running along with other useful info like uptime, foreground command etc.. This command takes an optional argument "-a" which shows all the containers, including the stopped ones. 

Step6: Let us stop and start the container again. We'll need the container id obtained from the docker ps command
# docker stop 3af04d663b3d

# docker start 3af04d663b3d

Above commands are a part of workshop which I have conducted before at Flock and CentOS Dojo. Check out the slides here.

Thursday, November 27, 2014

Encrypt Everything: Encrypt data using GPG and save passwords

Data security is an important concern these days and encryption is a very powerful tool to secure the data. In my previous post I talked about how to encrypt a disk. Now we are going to talk about how to encrypt files using GNU Privacy Guard (GPG).

GPG uses public key cryptography. This means that instead of having one key to encrypt and decrypt, there are two keys. One of these keys can be publicly shared and hence is known as public key. The other key is to be kept secret and is known as private key. Anything encrypted with public key can only be decrypted with private key.

How to encrypt files?
Assuming a scenario that user "test" wants to send an encrypted file to me, the user just has to find my public key, encrypt the data and send it to me where I will be able to decrypt the file using my private key and obtain the data. Note that user "test" doesn't need to have GPG keys generated in order to encrypt and send data to me.

Step1: Let us create a text file which we'll encypt:
test$ echo "This is a secret message." > secret.txt

Step2: User "test" needs to find my keys. There are many public servers where one can share their public key in case someone else wants to encrypt the data. One such server is run by MIT at
test$ gpg --keyserver --search-keys

Step3: Once the user obtains my public key, then encrypting data is really easy.
test$ gpg --output secret.txt.gpg --encrypt --recipient secret.txt

The command above will create an encrypted file named secret.txt.gpg which can be shared via email or any other means. Once I get the encrypted file, I can decrypt it using my private key
aditya$ gpg --output secret.txt --decrypt secret.txt.gpg

How to create GPG keys to receive data?
Now assume a scenario where "test" user wants to create a set of GPG keys in order to share the public key and receive encrypted data.

Step1: Generate a key pair. The command will present you some options (stick to defaults if you are not sure) and ask for some data like your name and email address etc.
test$ gpg --gen-key

Step2: Check the keys.

test$ gpg --list-secret-keys
sec   2048R/E46749BB 2014-11-23
uid                  Aditya TestKeys (This is not a valid key) <>
ssb   2048R/C5E57FF2 2014-11-23

Step3: Upload the key to a public server using the id from the above.
test$ gpg --keyserver --send-key E46749BB

Now others can search for the key, use it to encrypt the data and send it to the "test" user. 

To use GPG for saving password, have a look at pass utility. It uses GPG to encrypt passwords and other data and store it in a hierarchical format. 

Saturday, November 22, 2014

Encrypt Everything: How to encrypt the disk to protect the data

Recently, at, some of our services got compromised. We use Amazon Web Services extensively. The person (or group) who attacked us mounted one of our backups and managed to steal some of the data. We could have prevented this simply by ensuring that we use encrypted disks which would have made this attack useless. Learning from our mistakes, we have recently started encrypting everything and I am going to show you how to do that. One point worth noting here is that Amazon AWS does provide encryption support for the EBS volumes but that is transparent and would not help in case of the account getting compromised. I am going to use dm-crypt which is supported by Linux kernel so the steps are quite generic and would work on any kind of disk, on any kind of environment, including Amazon AWS, Google Compute Engine, physical disks in your datacenter.

Our goal is to encrypt /home. To achieve this, we'll attach a disk, encrypt it, move the entire /home data to this disk and create a symbolic link to /home.

Step1: We are going to use Linux Unified Key Setup. For that we need to install cryptsetup package.
# yum install cryptsetup

Step2: While using AWS, never attach the volume to be encrypted while launching the instance. If we do so, the instance will fail to boot up next time because it'll ask for decryption password while booting up which is not possible to supply in AWS. Still if it is absolutely mandatory to do this then I suggest trying to remove entries from fstab and crypttab but it is much easier to just attach the disk after the launching of the instance is done. Assuming that the attached disk is available at /dev/xvdf, we'll setup the encryption now.
# cryptsetup -y -v luksFormat /dev/xvdf
This will overwrite data on /dev/xvdf irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:

Command successful.

We can verify the encryption parameters as well. Default is AES 256 bit.
# cryptsetup luksDump /dev/xvdf

Step3: We'll open the device and map it to /dev/mapper/home so that we can use it.
# cryptsetup luksOpen /dev/xvdf home
Enter passphrase for /dev/xvdf:

Step4: This step is optional. To further protect our data, we can zero out the entire disk before even creating the filesystem.
# dd if=/dev/zero of=/dev/mapper/home

Step5: Now we'll create a filesytem
# mkfs.ext4 /dev/mapper/home

Step6: Let us mount and copy the data from /home
# mkdir /myhome
# mount /dev/mapper/home /myhome
# cp -a /home/* /myhome/
# rm -rf /home
# ln -s /myhome /home

Great! Our /home directory is encrypted. But wait a minute.. this approach has a short coming. We have deliberately designed it so that the disk won't auto-mount during the boot because there is no way to give it a password in cloud environment during the boot. Since the disk won't mount, we won't be able to ssh into the machine because the authorized_keys file is kept inside the home directory of the user. To address this problem, either change the "AuthorizedKeysFile" in sshd_config or create a user with home directory in /var/lib or /opt and grant sudo for cryptsetup and mount commands. So after reboot, if we take the first approach, we would be able to ssh without any problem or we'll ssh via other user, mount the encrypted drive and then use it normally.

$ ssh mountuser@<ip>
$ sudo /sbin/cryptsetup luksOpen /dev/xvdf home
$ sudo /bin/mount /dev/mapper/home /myhome/

Couple of points to remember:
  • Do not forget the LUKS password. It cannot be retrieved, if lost.
  • Try it a couple of times on staging machines before doing it on the machines that matter.