Latest

What is Shellshock?

What is the Shellshock Bash Vulnerability?

Shellshock is a recently discovered vulnerability that allows attackers to execute code on a system and set environment variables. The variables could be used to execute other more powerful commands.

What is Bash?

Bash stands for Bourne Again Shell. Bash was first released in 1989, the bug was introduced in version 1.14 and has been in place till version 4.3. This makes the vulnerability over 20 years old.

How do I know if my system is vulnerable to Shellshock?

To verify if your system is vulnerable, first you need to be running Bash. If you have Bash installed, executing the following command will output if you are vulnerable or not.

If your system is vulnerable the following result will be displayed on your screen:

If you got the message displayed above you will need to update your Bash installation.

If your system is not vulnerable to Shellshock then the following will be output to your screen:

How to patch my machines against Shellshock?

Patching against Shellshock is as easy as updating Bash on the machine. Below are the commands for updating the various Linux operating systems:

Centos, Fedora, or Red Hat

 Debian or Ubuntu

 

How to install the EPEL Repo on a CentOS 7 and RHEL 7.x

What is the EPEL Repo?

EPEL stands for Extra Packages for Enterprise Linux. This is a package repo based on Fedora and it is managed and maintained by a Fedora Special Interest Group. The EPEL Repo contains many packages that are not shipped in the official CentOS or RHEL releases. They are very much compatible but are not officially supported.

How do I install the EPEL Repo on CentOS 7 or Red Hat Enterprise Linux 7?

Assuming you are logged in as root or have sudo access, then you only need one command:

Example output:

How do I verify that the EPEL Repo installed correctly?

You can view the installed repos by using the yum command:

Example output:

As you can see in line number 10 the EPEL repo is now installed and available on your system.

 

 

How to install PostgreSQL 9.3

This tutorial explains how to install PostgreSQL 9.3 on a CentOS 7 or RHEL 7 machine. It goes through the process of how to get the latest version of PostgreSQL through the very basic configurations needed to boot up the server.

Adding PostgreSQL Repository

CentOS ships with PostgreSQL installed available in it’s default repositories. It may not be the version you would like to install. For example CentOS 7 has PostgreSQL 9.2, while CentOS 6.5 has PostgreSQL 8.4. The current version of PostgreSQL is 9.3. For that reason we are going to add the PostgreSQL repority to our list of available repositories.

 Available Packages

PostgreSQL has quite a few packages available. For our purposes we only care about the server and it’s dependencies. But if you wanted some of the other utilities, like pg_upgrade(), you will need to install the contrib package. Or if you want to enable the Perl extension, then install the plperl package. Here is a listing of the available packages:

 Install PostgreSQL 9.3

To install PostgreSQL just run the yum install command as follows:

Initialize PostgreSQL 9.3

Before we can do anything we need to initialize PostgreSQL. This creates the database cluster and all the file and directories needed for PostgreSQL to store the database.

Configure PostgreSQL 9.3

By default PostgreSQL listens on localhost. To enable it to listen to any available address we must change this value either listen on all addresses with * or to a specific address. To do this we must edit the postgresql.conf file. This file holds all of the configuration parameters for PostgreSQL. The postgresql.conf file is stored in the data directory in our case on /var/lib/pgsql/9.3/data/.

Let’s set the listen_addresses to listen to all IP’s assigned to the machine:

Now PostgreSQL will listen on any external IP available.

In order to allow clients to connect from anywhere except the localhost, we must allow them by editing the pg_hba.conf file. This file also is stored in the data directory.

Let’s suppose you want your PostgreSQL server to accept connections from anywhere in your network. Your network range is 192.168.1.0/24. Then we would add the following line to the pg_hba.conf file:

Defining the above we are adding connection socket of type host which can be any TCP/IP socket connection, this is for all available databases and all available users. From connections comming from the 192.168.1.0/24 network and are being authenticated with md5 encrypted passwords.

You can add the settings manually or run the following command, which you should edit to accommodate your network range.

Start PostgreSQL 9.3 Server

Now that we have our server configured with basic settings we can start it.

You can run any of the two following commands to start PostgreSQL

To start PostgreSQL on startup enable the boot service

Check PostgreSQL 9.3 is Running

If you want to check the status of PostgreSQL

Login To PostgreSQL 9.3

To login to the PostgreSQL server we must change user to postgres. If you are logged in as root:

Once logged in as the postgres user execute the psql client command:

You are now logged into your new PostgreSQL 9.3 database.

 

If you followed all the instructions correctly you now have a running PostgreSQL 9.3 server on a CentOS 7 or RHEL 7 machine.

 

How To Calculate A PostgreSQL Database Size

Knowing where you stand on disk usage is really important in a database. The last thing you want to do is run out of disk space. The following tutorial will list some simple commands to help you find or calculate the disk usage of several PostgreSQL objects. This includes tables, indexes, views, tablespaces, and so on. For the following examples I used the PostgreSQL 9.3.2

How to find the largest table in a PostgreSQL database

To get the largest table we need to query the pg_class table. This is a catalog containing pretty much anything that has columns or is similar to a table. We can get the ten largest tables with the following query:

Once we execute the query we get our results:

Defining the above SELECT:

  • relname is the name of the object. This could be a table, index, or view
  • relpages is the  size of the given table in pages. This is only an estimate and is updated periodically.
  • relkind is the type of object and is defined as follows: r = ordinary table, i = index, S = sequence, v = view, m = materialized view, c = composite type, t = TOAST table, f = foreign table.

A note on pg_toast tables. TOAST (The Oversized-Attribute Storage Technique) tables are created when the data set of a table is too big. By default PostgreSQL uses 8kB page sizes. If tuples are larger than 8kB they cannot span multiple pages. To fix this, large values are compressed and split up into multiple physical rows.

How to find the largest index, sequence, view, materialized view, or composite type in a PostgreSQL database

Similar to our query for finding the largest table, however now we look for a different type of relkind value.

How to calculate the disk space used by a PostgreSQL database

The pg_database_size() function will return the file size in bytes of a given database. It only accepts one parameter which is the database name.

The output is returned in bytes. To print out the size in a more user friendly format we can call the same pg_database_size() function, but this time we pass it into pg_size_pretty().

How to calculate the disk space used by a PostgreSQL table

There are two functions for retrieving the disk usage of a table. The first, pg_relation_size() which returns the size of a table excluding the index.

The second option, pg_total_relation_size() which will include the index and toasted data.

How to calculate the index size of a table

pg_indexes_size() returns the physical disk usage of only indexes for a particular table.

How to calculate the size of a PostgreSQL tablespace

Lastly we calculate the size of tablespaces, this we do with the function pg_tablespace_size().

 

How do I install Ansible on Linux

What is Ansible?

In short is an automation tool. With Ansible you can automate code deployments, server configurations, automatic updates. It can do this on one machine or hundreds of machines. The big difference between Ansible and it’s competitors is with agentless interactions. Ansible does all of it’s interaction with the machines via SSH, therefore all that it needs is a playbook and SSH credentials to a remote machine. A playbook contains all of Ansible’s configurations and tasks to be executed. A playbook is written in YAML.

Installing Ansible

Ansible is readily available in Fedora 20. However CentOS 7 and RHEL 7 users are required to install and configure the EPEL repo. For more information on installing EPEL follow my EPEL installation tutorial.

For CentOS 7, RHEL7, or Fedora 20:

For Ubuntu 14:

Make sure we have required software that might not already be installed

Add the Ansible repository

Update packages

Install Ansible itself

Verify installation

Now that we have installed Ansible we can verify that it’s installed by getting the version

If the above command returns the Ansible version, then congratulations are in order as you have successfully installed the latest version of Ansible.

How to create a Centos 7.0 Vagrant Base Box

This tutorial is aimed at allowing you to create a Vagrant base box which contains Centos 7.0. Vagrant allows you to create and share virtual machines with anybody. There are two ways of using Vagrant boxes, either you create them or you can import one. You can import one from the internet or any other medium. In this tutorial I will show you how to create your own Centos 7.0 Vagrant box. I usually create my own boxes as it allows me to only install the software that I need or want.

Tools you will need:

* VirtualBox – https://www.virtualbox.org/
* Centos 7.0 – http://www.centos.org/download/

Let’s begin

1. If you haven’t done so already, download and install VirtualBox (https://www.virtualbox.org/)

2. Download Centos 7.0 (http://www.centos.org/download/). For the purpose of this tutorial I will be using the NetInstall ISO, but you may use any other ISO. I selected the NetInstall because of it’s small file size.

3. Create a new VM with VirtualBox. I have named mine centos7-vagrant.

VirtualBox Name

You may setup this box any way you want. As far as settings are concerned, I have selected the following settings:
– Memory: 2GB
– Hard Disk: 20GB fixed size

Memory Size

Memory Size

File Type

Hard drive file type

Fixed Size

Storage on physical hard drive

Drive Size

File location and size

4. Once your VM has been created go ahead and boot it up. It will ask you for a start-up disk. In my case I downloaded the NetInstall ISO. So I browsed and select CentOS-7.0-1406-x86_64-NetInstall.iso

Select Startup Disk

Select Startup Disk

5. Install Centos with any parameters you want. I selected a minimal install since I just want the basics and any special package that I need will be installed later.

Installation Summary

Installation Summary

6. Set the root password as “vagrant”.

Root Password

Root Password

7. Create the vagrant user. Set the username and password to “vagrant”

Create User

Create User

8. Once installation is finished and the VM restarts, login as root.

9. Now would be a good time to install the VirtualBox Guest Additions. NOTE: This is an optional step.

10. Now we need to install packages that are essential for Vagrant to operate within the VM.

11. Let’s enable some services at startup time. We need ntpd so that it sets the time up correctly every time you boot up the Vagrant box, and of course sshd in order to SSH in.

12. Disable iptables as it really is not needed for a Vagrant box. It would just get in the way.

13. Set SELinux to permissive mode.

14. Comment out requiretty in /etc/sudoers. This will allow Vagrant to apply changes during startup.

15. Add the vagrant user to /etc/sudoers file.

16. Create /etc/sysconfig/network-scripts/ifcfg-eth0 and add the following:

17. We must now add a public key for the vagrant user. You can use the default public key or create a custom one. You may find more information on how to create a custom vagrant public key in the following tutorial “Using custom Vagrant SSH public/private keys“. For now we are going to use the readily available vagrant public key.

Create .ssh folder on the home directory:

Copy publick key:

curl https://raw.githubusercontent.com/mitchellh/vagrant/master/keys/vagrant.pub >> /home/vagrant/.ssh/authorized_keys

Set the correct permissions:

Make sure everything is owned by the correct use:

18. Turn off the VM

19. To create your Vagrant Box you will need to package the VM you just created. The following command will package the VM into your home directory. You are free to change this directory by modifying the –output paramenter

The –output would be the destination of your Vagrant Box file, and –base is the name or UUID of the VM that was created using VirtualBox.

20. Create the Vagrantfile

21. Start the Vagrant VM

 

If all the steps where followed correctly then your vagrant box is up and running. To login to the machine just do

 

Using Custom Vagrant SSH Public/Private Keys

Sometimes for a Vagrant box you want to use your own public SSH key instead of the public one provided by Vagrant by default. Either you want to securely share the box or you are paranoid about security. Whatever the reason may be, you can setup a custom generated public key.

What you need to get started:

This tutorial assumes that you have the following:

  1. A working Vagrant box
  2. A public and private key combination

Copy the public key:

In order to use your custom generated public key we will need to copy it to the vagrant user’s authorized_keys file.

Assuming that you have your vagrant box running on localhost and port 2222. Then your public key has now been copied over to the vagrant user.

Modify the Vagrantfile

We need to tell Vagrant that we are using our own public key instead of the usual supplied one. To do this we need to modify the Vagrantfile. Open the Vagrantfile for your Vagrant box in your favorite editor and add the following config parameter:

The above config parameter is telling Vagrant to use your private key instead of the default one provided by Vagrant. You will want to give it the location of the private key you want to use.

Test the changes

You need to reboot your Vagrant box for the settings to take effect. Once the box is up try and SSH into the box. If you followed all the steps you can now try to SSH into your Vagrant box:

 

Reload PostgreSQL Configuration

PostgreSQL allows for many settings in their postgresql.conf file. Depending on your database you may need to tweak any of these settings to find the optimal performance or to work the way you want it in your environment. The easy way to apply any changes is just by restarting the database. But that would be counter productive, if your blog or application runs on PostgreSQL, then that would leave your users seeing an “Unable to connect to database.” error until the database starts up.

Luckily PostgreSQL has two options for applying changes made to the postgresql.conf without restarting.

1. With an SQL command

If you have a superuser credentials you can just execute the pg_reload_conf() function. This will apply any changes that have been made to the postgresql.conf.

2. With the terminal

It is possible to load changes done to the postgresql.conf file via the terminal. You will need to login as the postgres user or su into it if you have root access. Then execute the pg_ctl command with the reload parameter.

If your data folder is not in the default location, pg_ctl will complain

In that case you will need to give it the location. That is done by passing the -D flag followed b the location of the data folder

The current version of PostgreSQL I am using is 9.3.5. Not all versions of PostgreSQL offer the same settings, they may change over version numbers. Also not all settings are available to be changed on the fly. Some require that PostgreSQL be restarted to take effect. There are not many of these settings, but they are settings that you usually only set once. For example the ip and port number.

Below are all the settings available for PostgreSQL v9.3.5 on Centos 6.5 as returned by the SHOW ALL command. I have marked the ones that require a restart to take effect. All other can modified and applied either via the pg_reload_conf() function or the pg_ctl command.

 

SSH Public Key Authentication

Public key authentication is not only more convenient than entering a password but also far more secure. On any given day your server or machine if SSH is on default port 22 and you have a public IP, it will probably receive at least 1,000 login attempts. These are all automated processes created in order to gain access to a server. They are not after your server, but they are after any server they can get their hands on.

When you generate a public key you are creating a random encrypted password, which is not easily hacked and tied to your particular machine. Only the machine that has the matching private key will be able to gain access.

The steps for generating a public key are rather simple. First generate a private and public key on the local machine, then copy the public key to the host. It’s that simple, but let’s go through all the steps:

1. Generate the public key

Make sure you are logged as the user you want to generate a public key for. To generate the public and private key we are going to use the ssh-keygen command.

If you notice I passed the argument -t rsa this specifies that I want to use the rsa protocol for generating the key. I also did not enter a password. You may enter a password if you wish. It would defeat the purpose of password less authentication but it will make login more secure.

If you look at your home directory, there is now a .ssh folder. This contains your private and public key.

id_rsa is your private key and id_rsa.pub your public key.

2. Prepare your host to receive the public key

To copy your public key to your host you need access to it. So of course you need to have a password.

In order to copy over the public key we need to create the .ssh folder on your host. Login as your user and in your home directory create a .ssh folder and chmod it to 700.

We also need to create the authorized_keys file, this is where we will copy out public key into. This file contains all of the public keys that are authorized to login to this machine.

3. Copy the public key to your host

Go back to your machine and make sure you are logged in as the user you generated the public and private keys for.

Type in the following to copy over your public key. Replace YOUR_USERNAME with your user and YOUR_HOSTNAME_OR_IP with your host’s hostname or ip. The command will ask you for your password since you haven’t yet added the public key to the host.

Your public key is now setup on your host. You can now ssh into your host without the need of a password:

4. Optional – Delete your password from the host machine

If you want to be really secure, you can delete your password from the host. This will ensure that only the machine with the private key will have access to this user. Note, that if you ever lose the private key you will lose access to the host.

 

The Time Command

Often while executing commands in the command line interface I find myself nervous or anxious. Particularly if I am working in a production machine because I don’t know if and when a command I issued is going to finish. Knowing how long a command is going to take is very useful as I would be able to anticipate it’s completion instead of waiting and looking at a black and white terminal with no progress for hours. This is where the time command is very useful.

The time command is essentially a wrapper for any command executed in a terminal. The time command must precede any other command to be executed, for example:

The above command will copy big_file.tar.gz to big_file_copy.tar.gz and will return how long it took.

The time command will output to standard error three pieces of information. The elapsed real time, this is how long it took from the start of the call to it’s termination. The user CPU time, which is the CPU time spent executing the instructions from the command issued. The last bit of information is the system CPU time. The system CPU contains the time it took to execute the tasks from the command issued.

If we view the output of the copy command we issued earlier

We can see that it took 23 minutes to run through the entire command execution, from me hitting enter until the file was copied to it’s new location. Roughly 360ms for the CPU to execute all command related to cp , and about 1 minute and 25 seconds for the CPU to execute the tasks needed by cp to copy a file.

As you can see the time command is very useful as it allows you to time how long a command takes to execute. You can use it to benchmark scripts that you created, find out how long something is going to take before actually implementing it on a production machine, or you just want to know for curiosity sake.