Posts Tagged ‘security’

Securing Nginx and PHP

December 16th, 2011

This write up is intended for single-user systems where you are the only user expected to log in via shell/terminal/sftp (or at least people you actually trust). This collection of tips does not cover situations where you may have multiple users home folders or a shared hosting situation utilizing nginx and php-fpm. Generally speaking if you have to read this post for security tips you probably should not be allowing access to any other user but yourself in the first place.

If you do not care to read this whole write up, just remember one thing: `777` is not a magical quick-fix; it’s an open invitation to having your system compromised. (Script-Kiddies… can you say jackpot?)


Generally speaking your server, which will most likely be a VPS running some fashion of linux will already have a web service user and group. This will sometimes be www, www-data, http, apache, (or even nginx if a package manager installed it for you). You can run the following command to get a list of users that are on your system.

cat /etc/passwd

Both Nginx and PHP-FPM should run as a web service, on a Debian squeeze this would be www-data:www-data, or on FreeBSD www:www.

If your server was set up with root being the main user you should create an unprivileged user for handling your web files. This will also make it easier to handle permissions when uploading your web files via SFTP. For example the following command on a debian system would create a user named kbeezie which has www-data as the primary group.

useradd -g 33 -m kbeezie

Group ID #33 is the id for www-data on Debian Squeeze (you can verify with id www-data). You may have to su into the new user and change the password (or usermod to change). This will also create a home folder in /home/kbeezie/ by default. You can log in via SFTP to this user and create a www folder if you wish. You’ll notice that the files will be owned by kbeezie:www-data, which will allow Nginx and PHP to read from, but also gives you group-level control over how the web services may treat those files.

This is ideal since you’re not giving nginx or php-fpm too much control over the user’s files and they can be controlled with the group flag. You could also create the user with it’s own group such as kbeezie:kbeezie and just change the group of the web files to www-data where appropriate.

SSH Options

It is usually advisable to disable Root access via /etc/ssh/sshd_config with the following line:

PermitRootLogin no

However make sure you can log in with your new unprivileged user via SSH, and also make sure that you can `su` into root permission. On a FreeBSD system only a user belonging to the wheel group can su into root, and only a user listed in the sudoers file can use the sudo command. However on Debian/etc the user could have www-data as it’s own group and still be able to su/sudo as long as the root password is valid. Your password should be at least 12 characters long and contain digits, symbols and at least one capital letter. Do not use the same password for root and your web user.

Once you’ve verified that you’re able to obtain root status with the new user you can safely disable root log in via sshd_config and restart the ssh deaemon.

You should also change your default SSH port, which is 22. While a port scanner could probably find the new SSH port it is usually best practice not to use the default port for any type of secure access. Like before make sure you can log into the new port (you can configure sshd_config to listen to both 22 and another port to test this out).

SSH – PubKey Authentication

If you are on OSX or another unix/linux operating system, like I am, setting up pub key authentication is fairly painless. Logged in as your web user on the server you can run the following command:


The above by default will ask for a passphrase for your private key as well as a destination to save both the id_rsa and files (which will normally be ~/.ssh/). You can then copy your own user’s public key to an authorized_key file with the following command.

cp ~/.ssh/ ~/.ssh/authorized_keys

Then on your own computer you can run the ssh-keygen command as well, copy your own computer’s public key from the file and add it as another line to your server’s authorized_keys file.

If you have `PubkeyAuthentication yes` listed in your sshd_config file with the authorized key path being that of .ssh in your home folder the server should allow you to log in without prompting you for a password. Just remember that if you chose not to use a passphrase for your private key then it is possible for anyone who obtains your id_rsa* files to log into your server without being prompted for a password.

You can even turn off password authentication completely and rely solely on public key authentication by setting `PasswordAuthentication no` in your sshd_config file. However keep in mind, unless you have another means of getting into your server you might get locked out if you lose your public/private key or access to the machine you use to log in (also not every SFTP or Terminal application supports pub key authentication).

I actually have public key authentication set up with my iPad using iSSH for quick server access on the go (and you do not need a jailbroken iPad for this).

On the next page are some Nginx and PHP specific configurations to hardening your installation.

Securing a Thumb Drive with TrueCrypt

January 15th, 2011

Thumb drives (aka flash drives) are extremely useful storage devices; they’re portable and easy to use, and with growing capacity used by more people every day. However they are more easily lost or stolen. Most thumbdrives offer no prevention against exposing the data within to unauthorized access.

Using Truecrypt 7 you can encrypt an entire thumbdrive (or create an encrypted container within for more novice users). The software works on Windows, Linux and Mac OS X. For this article we’ll look at using an entire thumb drive as an encrypted device, so that without decoding it’ll simply look like an empty or corrupted drive when plugged in by an unauthorized persons. The best thing about TrueCrypt is that it’s free and powerful, so effective in fact that FBI Technicians have been unable to crack a Truecrypt 5.1 volume used by an alleged suspect since 2008.

Preparing the Thumb Drive

It goes without saying that if you already have information on your drive, that you’ll want to back up it’s content as this procedure will erase all the existing data.

First thing we need to do is remove any existing partitions on the device, since I’m a Mac user I’ll illustrate this with Disk Utility. For windows users you can use these instructions to remove any partition on the device. I’m assuming most linux users know how to do this with their own preferred utility such as gpartd.

In Disk Utility select the device on the left, then the partition tab, select “1 Partition” with a format of “Free Space”, then click Apply.

Once you have done this, the device will be completely empty and be ready to be used completely by TrueCrypt.

Encrypting the Thumb Drive

First we’ll want to install and launch the TrueCrypt software on your system, and click the Create Volume button. You’ll be prompted with this screen, from here select that you would like to create a volume within a drive or partition.

You’ll then be asked to select your device, you may be prompted for your system password at this point. From the list select your now-empty device from the list.

From here select the Volume Type. For this article we’ll use a standard volume. The hidden type is useful if you wish to have an extra layer of protection. The hidden volume will only open with the use of an alternate password, this gives you a level of plausible deniability in case for legal or extortion reasons you’re forced to give up the password to the device, in which case you can simply provide the password for the normal volume.

Then you can select your encryption options. AES is the default and typically the fastest, especially with processors that now have hardware acceleration for the AES algorithm. You can click the benchmark button to see how fast your current system can encrypt/decrypt the various algorithm methods. With a very strong password the AES method is usually just fine. I usually stick with the RIPEMD-160 hash algorithm, but you can choose to use one of the larger 512bit options. If you went with the Hidden Volume option above, you’ll have the chance later to select a different method for the hidden volume.

Now select a password, I recommend a strong password, something over 20 digits, and uses a mix of letters, numbers, and symbols. The longer the password, and the more variety of passwords you use the harder it will be for even brute force method to crack. For example a 6 letter password using letters could theoretically be cracked in 5 minutes by an old Pentium 100mhz computer, mixing upper and lower case characters would increase that time to 5 hours on the same machine.

Now days a typical quad core desktop could crack the above scenario using brute force in as little as 3 minutes, but an 8 character password using both upper and lower case letters, plus numbers and symbols would likely take a 100 years to crack. So adding some variety to your password such as symbols and using something longer than 8 characters goes quite a long way to prevent a simple brute force attack from succeeding. For more information on possible scenarios and how long they may take to crack refer to this link, for the most part most multi-core computers now days fall under “Class E”.

A keyfile option will give you an extra level of password protection, but keep in mind if you lose or change the keyfile on your computer, the encrypted volume may become unrecoverable. It’s also impractical if you wish to use the thumbdrive from a number of different computers.

If you wish to use the thumbdrive with multiple operating systems, FAT format will be your best bet. If you choose to use the Mac OS Extended option, you’ll be asked later if you wish to use the drive on other operating systems as well as if you wish to store files larger than 4GB.

If you had previously sensitive information on your device, do not choose the Quick Format option. Otherwise when someone attempts to use recovery software they may be able to see the data left behind prior to the encrypting.

On the volume format window you will be asked to move the mouse randomly within the window for a while. This will help seed the hashing algorithm for stronger cryptographic strength. Once you’ve sufficiently moved the mouse about you can click the format button. Depending on the speed of your device this can take a few minutes.

And now your volume has been created:

If you remove, then reinsert your thumb drive you may be prompted with a message like below, you can saftely ignore this message and proceed back to the TrueCrypt application.

Within TrueCrypt you can select a device and mount it, again selecting the seemingly-empty device and then provide it with your password.

Once mounted it’ll appear on your computer as just another volume. Encryption and Decryption occurs in the memory, so even if your computer were to suddenly shut off, or the device were to be pulled from the computer, the data on the device is still encrypted. On OS X you normally want to eject the volume from finder before dismounting it from TrueCrypt.


The most obvious down-side is that you will need to have TrueCrypt installed onto any system you wish to use the thumbdrive on. However if you choose to do a container volume, you could simply use the thumbdrive as a regular device and store your important stuff as a file container on your thumbdrive. The encrypted device would no longer simply be plug-n-use, you would have to open truecrypt, select your device and provide a password in order to mount it. But on the plus side, to anyone who may steal your drive it’ll just look like a corrupted/empty device to them.

The other impact is speed, encrypted data takes longer to read than normal data straight off the device. However even on my 3 year old macbook, and a couple old thumbdrives I have not noticed much of a difference accessing and using files than when unencrypted.

I’ve tried this on an 8GB PNY Micro Attache Slide (one of my favorites, very cheap, tiny, and has a high read speed) and 16GB Sandisk Cruzer as well as a 16GB PNY Attache Mini (from the above screenshots) without a problem. The write speeds are usually much slower than the read speeds on the above devices. My Micro Attache has very slow write speeds, but a very nice read speed so I tend to use that a lot.