Category: Devops

Hashicorp Vault , keeping things secret – Part 1 install and configure Vault

Hello folks

Today I am going to talk about a great tool from Hashicorp, it’s called Vault (https://www.vaultproject.io) . This piece of software is in my opinion an essential part it our Devops toolkit. It allows you to safely save, and dynamically generate secrets for your infrastructure. The main use case for me has been to allow me to set passwords in Terraform templates, without exposing the password itself in clear text,  but for now what I am talking about here is how to install it and get it up and running in your Linux Server, and I will also provide a Dockerfile you can use to spin up a container and play around with vault.

So let’s get our hands dirty

1 – Download your binary from https://www.vaultproject.io/downloads.html , you will see links for MacOS, Linux, BSD etc, choose your own . For example

#wget https://releases.hashicorp.com/vault/0.8.1/vault_0.8.1_linux_amd64.zip

2 – Uncompress the archive and copy the file into a directory in $PATH

#unzip vault_0.8.1_linux_amd64.zip ; cp vault /usr/local/bin

3 – Test that tou can execute vault.

#vault -v

this should return something like

#vault -v
Vault v0.8.1 (‘8d76a41854608c547a233f2e6292ae5355154695’)

Of course your values could be different as newer versions are released. You should also do the same thing on your workstation as the same binary is used for the client too. So download it to your computer expand the zip file and copy it to a location of your choice (as long as that location is in $PATH).

So , now we have vault in place and we can start the server, this can be done by using the command

#vault server -config <PATH_TO_CONFIG_FILE>

output will look something like


==> Vault server configuration:

Cgo: disabled
Listener 1: tcp (addr: “0.0.0.0:8200”, cluster address: “0.0.0.0:8201”, tls: “disabled”)
Log Level: info
Mlock: supported: true, enabled: true
Storage: file
Version: Vault v0.8.1
Version Sha: 8d76a41854608c547a233f2e6292ae5355154695

==> Vault server started! Log data will stream in below:

Please make sure your firewall allows port 8200/8201 TCP to this server.

If you want to use Vault inside a docker container you can checkout this git repo , as it contains a Dockerfile and an example configuration file for Vault.

https://github.com/ruimoreira/blogexamples

Ok so now we have vault running. Lets initialize it , I would advise you execute this on your workstation,

export VAULT_ADDR='http://<VAULT_SERVER_IP_ADDRESS>:8200'

Let’s check that we can actually reach it

# vault status
Error checking seal status: Error making API request.

URL: GET http://127.0.0.1:8200/v1/sys/seal-status
Code: 400. Errors:

* server is not yet initialized

so this tells us that we can indeed reach the server, however it’s not initialized.

So let’s do just that.

#vault init


#vault init
Unseal Key 1: IIeMHIGq+xmIDqXN7Q43Lt7nmi5sLvNad5NgUjOVPoiA
Unseal Key 2: phNTpSyjBqobHYeLVOfiaUHQ6iidw2/BowKnTb3HzaC4
Unseal Key 3: jJcuYrSiQRHv0TvD1/AVrHBpd2f6mjtjriGLa66A2O5b
Unseal Key 4: so5WqFp1nmXFeuLE4tUZiglCTEBP2gkc9/teNZNvVOmz
Unseal Key 5: hCNg3wwVfYY/x0A6TLVmvyKyutilr5qvhkiH4mUDHWXR
Initial Root Token: 880fde6a-f672-fe8e-50d0-2e51f566654a

As we can see vault has provided the Unseal Keys, and the Root token to authenticate with.

At this point you need to unseal the vault, and you need to provide 3 keys using vault unseal.

Hope you find this useful and hope to see you again soon.

 

Rui Moreira

PS: If you are using a docker container to play around with Vault, the I would like to remind you to use the -p option to expose the port of the container you are running vault on.

More information here

WordPress Security and Selinux

Hello all,

Here we are again, today I am going to address WordPress, and the security of said platform, and how it could relate to Selinux, and SELinux in general.

Many have claimed that wordpress is in itself a flawed plattform and inherently insecure, I could not disagree more. Of course as with every web application there are a lot of security aspects to be taken into account and this should not be taken lightly. In my opinion there are a few things we could do to increase the security of our wordpress install and our website’s reputation intact or at least not at permanent risk. As most of you know I have in the past worked for one of the most famous hosting companies in the world, the Birthplace of Openstack and overal an awesome place to work at, and during my carreer there I have seen a lot of nonsense around wordpress installs, well the same could be said about several other CMS plattforms but I have to admit that WordPress is one of the most famous, amongst other things I have seen the following errors, but however there are others, these are just the most common :

1 – apache user owning the document root

2 – chmod 777 on the document root

3 – features developed that prevent wordpress or php from being updated

4 – outdated or exploitable plugins

5 – Selinux disabled

Let’s look at each one of them indivudually ,

1 – apache user owning the document root

This is very dangerous and will allow an attacker to exploit possible failures in wordpress to write to the document root of your website, the attacker will then use the file he or she uploads (usually a malicious script) to eventually download some sort of php shell (a piece of software that mimics the functions a shell would implement) and try to take control of your web server and website.

While installing wordpress take into attention the file permissions and the recommendations in the WordPress codex (https://codex.wordpress.org) regarding file permissions. Basically apache needs to be able to write to wp-content/uploads and not much more. If you plan on updating wordpress via the ftp feature, please create a user for that process that user could own the entire document root with apache only to read the files. Also if you are doing this please resctict the ftp process to localhost, as ftp is somewhat insecure.

2 – chmod 777 on the document root

This one is a big no … if your website has chmod 777 in the document root I would suggest that you place it under maintenance and review all the file permissions to what they should be. again the wordpress codex is a good place to start.

3 – features developed that prevent wordpress or php from being updated

This one is my pet peeve, it should never happen your developer should test if his code will still work in the case of a upgrade on wordpress at least. We could argue that if some function gets deprecated in a php version upgrade and that breaks your code, you should in my opinion pay your developer to perform the correct fixes. This might sound like I am parcial to developers, however I do insist that they should not work for free (nobody should really) and if your website’s reputation is important for you then you need to agree with him on  how to proceed. But the wordpress version upgrade should be starting point even before your website goes to production .

4 – outdated or exploitable plugins

This one is really a must, as I have said keeping wordpress and it’s pluggins updated is vital for the security of your website.

5 – Selinux disabled

In my opinion we should never have SELinux disabled, there are always ways to make it work and with the tools we have available (audit2allow, audit2why , etc ) there is no reason why you should have it disabled, instead learn how to use it, embrace it, at least if you are serious about security and about the website you are hosting. If you are not then you have no business hosting a website in the first place .

On my next post I will talk about ways you can improve the performance and perform some basic hardening of your wordpress instance.

Until then … stay safe !

 

Cheers

Rui

 

Ansible modules development

Hello again

So as a hobby I have started working on an Ansible module to allow adding static routes to several hosts , I got out my recently acquired Python skills and started cracking at it , if you are curious about how to start developing ansible modules here is a good place to start . the module development itself is not hard to get started with , and if you are already familiar with ansible and python ( in fact you don’t need python as you can write modules in any language but I have chosen python  for mine ) if should be fairly straight forward.

I have chosen this module for implement because it seems that it is a common thing to do as a System Administrator and there is no specific module to do this, of course you could just use the command module to add a static route but this module aims to do a bit more than just that, I am thinking about implementing this for the most relevant unix like platforms , namely :

 – Linux

– Red Hat

– Debian

– Ubuntu

– BSD

– Openbsd

– Freebsd

– Solaris

If I can find the time and resources I will try to implement the same for also HPUX and Aix but as I don’t have direct access to those platforms at the moment I cannot promise that I will do so. For now the priority is Linux of course .

The code is available from my github repo but for now it’s just an embryo.

Cheers

 

Rui