How to use and create vps hosting service in india

Security should be a primary concern for any kind of data that stored on an internet accessible computer. While every storage provider should take care to secure data from their end, this only goes so far as unauthorized access can happen through software flaws of services on your server, g,social engineerin and many other avenues. In short, you should take ownership of the encryption and security of any data that you cannot afford to fall into the wrong hands.

Add caption

There are many ways to encrypt content on a Linux system. Many of these options rely on encrypting separate partitions, devices, or filesystems. This may not be an option if you are dealing with a system like a VPS. However, there are other options, such as creating a file that operates as a device in order to store encrypted data.

In this guide, we will use the dm-crypt tools to create a large encrypted file that can be used to store our sensitive data. We can then mount this file as if it were a regular partition. We will be demonstrating this on an Ubuntu 12.04 VPS instance, but similar procedures should work for other distributions.

Basic Idea

The dm-crypt is a kernel-level encryption mechanism which offers transparent disk encryption. This means that the files are immediately available without any additional interaction after mounting.While most encryption schemes rely on encrypting things at the partition level, we can get around this by using a file that we mount as a device mapping target. We do this by mounting the file as a loop device. We can then store data on this mounted "device" just like we would with any other partition or device.When considering implementing any kind of encryption, you need to weigh some pros and cons. First of all, there is always a performance overhead involved with encryption. This may or may not be significant, and we recommend that you create a small file first to run tests against before implementing this on a larger scale.

Add caption

Another consideration is recovery. Encryption, by virtue of its primary function, makes recovery more difficult. If you forget your password, your data is effectively lost forever. If your LUKS header is overwritten or damaged, your data is also lost forever. If your system is not booting and you need to access information in your encrypted file, you will have to go through a more complex process to gain access.When making a decision to encrypt data, you need to be aware of the possibility of losing that data if something goes wrong. You should definitely backup any of the data, and dm-crypt provides a lot of information about how to do that here.

Add caption

Installing the dm-crypt Tools

While the kernel-level functionality should be available in your distribution, the actual front-end tools probably are not installed by default. All of the commands in this guide will be performed as root.We can get the necessary tools by updating our local package index and installing the dm-crypt tools:

Create a Non-Sparse Empty File

To store our encrypted data, we need to create a file which will act as our storage device.We want to create an empty file, but we can't have that be a sparse file, which doesn't actually allocate the full file size when it is created. We can do this in a variety of ways.

The easiest and the quickest way of going about this operation is with the fallocate command. This instantly allocates the amount of disk you would like for a file and assigns it the filename you give it.For instance, to create a 512MB file on in our root user's home directory, we can type:

fallocate -l 512M /root/test1

This is incredibly fast, but it does have a disadvantage that it will not overwrite whatever old, deleted data that used to be used by those blocks with zeros or random data. This probably will not be desirable for your purposes because we don't want people to be able to tell which portion of the file has encrypted data written to it.

Another alternative is using the ubiquitous dd command. We can write zeroes to the entire area that we are provisioning to our file by using the /dev/zeropseudo-device. We could create a similar file to the one above by typing something like:

dd if=/dev/zero of=/root/test2 bs=1M count=512          

If instead, you would like to write random data, which should mimic the encrypted data that will actually be written to it, you can use one of the random pseudo-devices instead. This will take quite a lot longer, especially if you are allocating a large file, but using the random devices is probably is the best way to provision a file for this purpose:

dd if=/dev/urandom of=/root/test3 bs=1M count=512

Using the /dev/random pseudo-device is an even more secure way of doing this, again at the expense of time:

dd if=/dev/random of=/root/test4 bs=1M count=512 

Add caption

Creating and Mounting the File System

Now that we have a LUKS container created and it is opened as a regular device in our system, we can begin doing regular device operations on it.

First, we need to format and create a filesystem on our device. You can choose whatever filesystem you'd like. We will use a standard Ext4 filesystem, but you can use any filesystem that your server is configured to handle normally.

For our purposes, the command we want to use is:

mkfs.ext4 -j /dev/mapper/volume1

We now have a filesystem written on top of our LUKS container that is contained in our file. Since it is being handled like a device, our next step is logically to mount the device.

Let's create a mount location that will make sense:

mkdir /mnt/files

Now, we just need to mount our filesystem:

mount /dev/mapper/volume1 /mnt/files

You can now see our file as part of our available filesystems:

df -h

Filesystem           Size  Used Avail Use% Mounted on

/dev/vda              59G  2.7G   54G   5% /

udev                 2.0G   12K  2.0G   1% /dev

tmpfs                791M  216K  791M   1% /run

none                 5.0M     0  5.0M   0% /run/lock

none                 2.0G     0  2.0G   0% /run/shm

/dev/mapper/volume1  486M  2.3M  459M   1% /mnt/files

You can see that some of the available space in our file has been taken up by the encryption overhead and the filesystem overhead. We still have most of our space though.

If we check out the location that we've mounted our file, we can see that it's been provisioned exactly like any other Ext4 filesystem:

cd /mnt/files

ls

lost+found

The normal lost+found recovery directory has been created. We can now write data to this location, and it will be placed, encrypted, in our file. For example, we can just take our /etc directory and copy it into the mount location:

cp -r /etc/* /mnt/files

Add caption

Conclusion

You should now
have the ability to create an encrypted file to store your sensitive data.
Remember that there is often a trade off between performance and ease-of-use
and security. Also, keep in mind that you must never lose the password you set,
because there is absolutely no way of recovering it.

While this is

not the only consideration necessary to protect your data, hopefully you can
add this to your toolbox in order to tighten up security on your Linux servers.
Add caption