This seems like a good starting point, blocking everything except SSH, established, loopback, and outgoing connections:
iptables -P INPUT ACCEPT iptables -F iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT iptables -L -v /etc/init.d/iptables-persistent save
On my Debian system, the last "save" line puts a reloadable copy of the current running iptables rules in /etc/iptables/rules.v4 & /etc/iptables/rules.v6. Thereafter, it is also possible (advisable?) to edit these files directly to add/modify rules. For instance to open up the http port, add the following line to /etc/iptables/rules.v4:
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPTThen load the new ruleset using:
iptables-restore < rules.v4
Update: This all works really well. I now encrypt my entire home directory on all of my machines, plus usually add another encrypted partition for things I do not think need to be backed up. I will leave this howto in the form of encrypting a home subdirectory, as I think that is probably still a good place to start for someone just sticking a toe in these waters.
Laptops are easily stolen. And these days, if you travel internationally, it is not uncommon for the thief to be Customs / Immigration agents who have the power to permanently seize your laptop on little or no grounds. All they need do is invoke the "National Security" bogey-man. Some thought should be given to protecting personal data, especially if setup seems easy.
In the title, I say "transparently" in the sense that once this is setup, everything should work just like before. Under the hood, though, you will have an encrypted subdirectory in your home directory, which is automatically mounted when you login, and unmounted when you logout.
I was lead to do this, finally, because this article makes it sound very easy and convenient. Obviously, it would be more secure to encrypt my entire home directory (or even the entire hard drive) but to do this for an already installed system is a bit more trouble and risk. Plus I would like to build a little confidence in my ability to not lose data first, before I commit myself entirely. This way I will protect (and risk) only my most sensitive data (and keep good backups elsewhere should something go wrong with the encrypted partition). On the other side of the ledger, encryption does add a certain amount of overhead to everything you do with the encrypted files, especially on an older machine. There is a reasonable argument, I think, for only encrypting what is necessary.
First step: Make a good backup. Messing with the partition table is risky business. Now use gparted to make space for an empty partition. Be warned that I shrank an 80G partition down to free up 1G, and this took a whole afternoon on a Pentium III, and making changes to your partitions is a process you *really* do not want to interrupt. So if you have a laptop, make sure your battery is charged to guard against power failures. Also note that changing the size of the encrypted partition later may not be easy, so be generous....
In Debian, install packages cryptsetup and libpam-mount, and then next we will create an encrypted volume out of the just-created empty partition hda7. This section is a summary of the corresponding section from .
Create the encrypted volume:
cryptsetup luksFormat /dev/hda7
LUKS most noteworthy feature is that is supports unlocking the encrypted volume with any one of several passwords. Now name the encrypted volume "mysecrets", and format it:
cryptsetup luksOpen /dev/hda7 mysecrets
Mount the encrypted volume and write a test file, and then unmount:
mount /dev/mapper/mysecrets /home/userid/protected/
date > /home/userid/protected/date.txt
cryptsetup luksClose mysecrets
Now verify that mount.crypt from libpam-mount will open the encrypted volume:
mount.crypt /dev/hda7 /home/userid/protected/
Mount the Encryped Volume Automatically on Login:
Unfortunately, at this point the advice from  stopped working for my circa November 2008 Debian installation. This was a bit disconcerting since  was only just published. However, a bit of poking around indicated that PAM is a bit of a complex beast, and that there was more then one way to get this to work. So next I tried the "Automagically mounting" section of .
As  says, for this to work, the user's login password must be the same as one of the passwords assigned to the LUKS-formatted encrypted volume we created in the preceding section.
Next we have to do something a little different then , since PAM has evolved a bit since  was written. Add the following block to /etc/security/pam_mount.conf.xml:
And that is it. user="username" means this block will only kick in when "username" logs in. The empty strings assigned to the last two parameters above apparently tell PAM to use the user's login password instead of a key file. Now log out, log back in, and you should find that /home/userid/protected has been automatically decrypted and mounted.
(Note: I have since taken to doing this for my whole user directory, and there seem to be permission problems on the first login that kick up some errors and lead to a read-only home directory. So, after the first login, do an Alt-Ctrl-F1 and login as root.) Then fix the permissions:
chown -R username:username /home/username
chmod -R 755 /home/username
Logout and login again, and everything should work.
Future password changes must also be separately applied to the encrypted volume, ie.
cryptsetup luksAddKey /dev/hda7
to first add a new password to the volume (up to a maximum of eight). Note that this will add the new password to the first empty slot, and not overwrite your current password, as the dialog might imply. Then change your Linux user password. And finally
cryptsetup luksDelKey /dev/hda7 0
to delete the oldest password, in the first slot, when you are ready. No rush. That is one of the advantages of using LUKS.
cryptsetup luksDump /dev/hda7
will tell you which password slots are in use (among other things) but obviously will not tell you what the passwords are.
I have been running with this setup now for well over a year, and am very satisfied as to usefulness and stability. The only irritation is that, since I am only encrypting a subdirectory of my user directory, after I login my encrypted directory will sometimes automatically unmount after a few seconds if nothing accesses any files in that directory. I just use a terminal to cd into the directory and lock it open the first thing I do after logging in. There is probably a more elegant way to resolve this issue....
I also think this solution is more elegant then what I have read about the new standard Ubuntu encrypted home directory, which though simpler to turn on at install time still requires you to store / remember an encryption key. My setup still only requires you to remember your user password to login and decrypt the user directory.
On a strategic note, if you are going to cross a border with your now-encrypted directory, I would suggest you create a dummy user account with a throw-away password. That way, if the immigration goons seize your laptop and insist that you give them "the password", you can give them one that does not matter, and in particular, does not unlock your encrypted directory. Likewise, make sure that the root password is not the same password as the user password that unlocks your encrypted partition, as they might be smart enough to demand the root password as well.
Create the logical volume:
lvcreate --size 200G volgroupname -n scratch
Format the volume:
Create an entry in /etc/fstab to mount the volume:
/dev/volgroupname/scratch /scratch ext3 defaults 0 2
Then create the /scratch directory and mount it.
"pvs" and "pvdisplay" lists all physical volumes,
"vgs" and "vgdisplay" lists all volume groups,
"lvs" and "lvdisplay" lists all volumes.
"vgs" displays the amount of free space that has not yet been assigned to a volume.
The Volume must be unmounted before it can be rduced:
Check the volume for errors:
fsck -f /dev/mapper/home/
Shrink the file system to 200G:
resize2fs /dev/mapper/home 200G
Shrink the LVM volume group to the same size:
lvresize -L 200G /dev/mapper/home
This seems to be really easy to forget:
will replace every occurance of old-string in the file with new-string. You can of course do more complicated things.