Help me decide how to secure my box

[zenlunatic]

First let me say that my only current system is a laptop. And just before you mention that I should install openbsd, understand that I have no need for industrial strength security, at least not yet, but I do like to think ahead.

I don't know too much about the various security applications and systems that Gentoo (linux) has to offer, so I was wondering if you guys could clear some things up for me.

First off what is the difference between the various firewalls that are available? Specifically I mean ipfw, pf, iptables, and ipf? How does netfilter and ipfileter play into all this? I know that ipfw started with freebsd, and linux adopted it, and then they wrote iptables for 2.4 kernel, and openbsd wrote pf because of some licensing/political issues. I would rather like to know the technical differences between the firewalls mentioned. How do they differ?

Secondly, whats the difference between gnupg and the various free PGP alternatives such as MIT pgp freeware? I understand that all the newest PGP programs by Network Associates are easily compatible with GNUpg. I don't use any type of email encryption at the moment, but I soon plan to make my first keys. Should I even consider things like PGP freeware for Gentoo, or is GNUpg pretty much defacto with all the interoperablitiy I would need?

Lastly, what is a good disk encryption system? I have heard that cfs/tcfs are outdated and old (the tcfs site doesn't even work properly). I have researched some commercial alternatives and found VPdisk and BestCrypt with linux support. I also stumbled across CryptFS and PPDD. Most people I talk to on irc seem to think CryptoAPI through loop devices is the best disk encryption method. Which method should I use?

[guero61]

1. Unplug it from the mains
2. Unplug it from your NIC
3. Remove/plug all media insertion points
4. Rip off keyboard/touchpad
5. Power off
6. Perfectly secure!!!

[Naughtyus]

As far as encryption goes, this thread has been very useful to me:

http://forums.gentoo.org/viewtopic.php?t=31363

[RdsArts]

First let me say that my only current system is a laptop. And just before you mention that I should install openbsd, understand that I have no need for industrial strength security, at least not yet, but I do like to think ahead.

OpenBSD? On a laptop?

..... No, I can honestly say that is not the first option that would have popped into my head. ^_~

That said, IMHO a firewall is a firewall, and using the one you know best is the best way to go. A firewall's only as good as it's configuration files, so it's best to just use what your comfortable with. If it's just for fun, experiment with them all.

[bsolar]

Moved from Gentoo Chat.

[jondkent]

dunno how much you know about firewalls, but the old ipchains kernel firewall in 2.2 is a stateless firewall whilst iptables in 2.4 is stateful, which is good and much easier to configure. Talking about configuration, doing it from the command line could be problematic is you haven't done so before, so you might want to look at fwbuilder, which is gui front end to building iptables rules.

[zenlunatic]

Talking about configuration, doing it from the command line could be problematic is you haven't done so before, so you might want to look at fwbuilder, which is gui front end to building iptables rules.

Yeah but in the long run I would rather like to learn the bottom line of a packet fileter. I hope the energy that I put into learning iptables will pay off, opposed to learning ipf, pf, or ipfw. I know those aren't generally linux packet filters, but I wan't to develop some marketable skills

[Durenunde]

1. Unplug it from the mains
2. Unplug it from your NIC
3. Remove/plug all media insertion points
4. Rip off keyboard/touchpad
5. Power off
6. Perfectly secure!!!

was that not microsofts advice to all people who wanted a secure server... though I think it was more along the lines of

1. just don't connect it to the internet

though its true a computer is only as secure as you can make it and people are going to find a way round it if they are determined enough.

Yeah but in the long run I would rather like to learn the bottom line of a packet fileter. I hope the energy that I put into learning iptables will pay off, opposed to learning ipf, pf, or ipfw. I know those aren't generally linux packet filters, but I wan't to develop some marketable skills

I think you are right in learning the command line fully and not going for the gooey. I started into linux about 3-4 weeks ago now and just dived into the command line and now I'm comfortable with it and have set up a good bit only with command line.... better for performance for a server as well.

Sorry no real advice for security... though its got me interested, I'll look into this myself, as I need some good security on my servers

[jondkent]

Yeah but in the long run I would rather like to learn the bottom line of a packet fileter. I hope the energy that I put into learning iptables will pay off, opposed to learning ipf, pf, or ipfw

Glad to hear it. Lots on information on line but be careful as some advise is just plain wrong. Might be best to buy a book (Red Hat Linux Firewalls is a good one and doesn't just cover RH)

Quite a fan of OpenBSD (luv the ability to mount drive ro or rw on the fly) and their firewall methods are pretty solid. Not that much documentation about mind.

Have fun

[kermitjunior]

1. Unplug it from the mains
2. Unplug it from your NIC
3. Remove/plug all media insertion points
4. Rip off keyboard/touchpad
5. Power off
6. Perfectly secure!!!

You forgot:

7. Unplug from wall
8. Turn off circuit breaker
9. Throw the "Main Switch"
10. Cut incoming power lines.
11. Bury machine in basement... preferably concrete.

Or you could "secure" it like a friend of mine did... take apart everything and throw it in a lake. Yep. That's pretty secure.

KJ

[jaeger_m]

12. Start all nukes in the world and destroy it.

But be avare of that a lot of people will be mad at you

[rajl]

on a more serious note of how to secure your box. I have a few pointers.

First and most obvious is to use a firewall. The bare minimum is to use a packet filter running on the machine you're trying to secure, though a better, more layered approach is to have a dedicated firewall box running squid (or something similar) in front of the box you're trying to protect. Also, do not run any unnesecarry servers, and especially do not run telnet or ftp servers. If you need the functionality of those, run an ssh server and if you need ftp, you can use sftp that's built into the ssh server. That's about all you can do to keep intruder's out of your box that I can think of off the top of my head.

Which leads to the next part of security, what you can do to make an attacker's life miserable if they gain access to your box. My first reccommendation is to use the encrypted root filesystem as mentioned above. I've never done it before because I've never had the time to do a reinstall...that and I'd prefer an all gentoo way . Second, I'd suggest storing as many of your logs as you can in some place other than the traditional /var/log/* because that is the first place attackers will look when they try to delete your logs to cover their tracks. If they can't find your logs to modify them, you'll have that much more information to use to fix the hole they found. Third, if you are able to, i'd recompile your kernel and take out kernel support for modules and turn your kernel from a modular one into a monolithic one. The reason is because most rootkits come as kernel modules that are inserted into the running kernel. If your kernel does not support modules, it renders most of these rootkits useless. This leads to number 4: compile the grsecurity into your kernel if you're running gentoo sources. It adds a number of kernel features that harden your system's security (such as randomizing process id's, etc) from the typical script kiddie attacks. I always use the low setting because it doesn't break any of my software programs, though if you know what you're doing, you could be much more effective using the customize option. Fifth, compile as little into your kernel as possible. The less code on your system, the fewer bugs there are to exploit.

More advanced tips. Download chkrootkit and run it as a cronjob. It won't detect every rootkit out there, but it covers all the basics. Think of doing this as the linux equivalent of anti-virus scans. If you're feeling REALLY, REALLY brave you can delete /usr/bin/sh. (Kids, do NOT try this at home). /usr/bin/sh is your basic, no-frills shell. It's also the only shell that's part of the posix standard iirc. Because it's part of posix, you are guaranteed to find it on any system implementing the posix standards (read every *nix system I can think of: linux, solaris, OS X, sunOS, the BSD's, etc), so rootkits almost always make use of /usr/bin/sh for portability's sake (easier to write one rootkit that uses /usr/bin/sh than a gazillion rootkits taylor made for the gazillion shells out there). The downside to deleting /usr/bin/sh is that it will break A LOT of valid scripts that you might want to use (example portage and most other program install scripts), because those valid scripts also depend on /usr/bin/sh for portability's sake.

Hope those ideas help or give you some thought on what else you can do to secure your system. Also, if you're using a laptop, setting a boot passwd in the bios is useful. It won't stop someone determined enough to take your laptop apart to reset the bios, but the casual punk who doesn't know that much about computers will look at it in dazed confusion and give up.


***edit***
the difference between gnupgp and the mit pgp freeware is virtually none. I don't know how much you know about cryptography, but the two programs use the same algorthims. They both offer your choice of either Diffie-Hellman, RSA, or DSA. MIT lets you use larger keys than gnupgp, but as long as you use anything at least 1024-bits long, you should be fine unless you're trying to hide from the NSA. The MIT program also includes some extra frills such as secure file deletion and harddisk free-space wiping.

Also, I forgot to include that you should consider including an intrusion detection system (IDS). Tripwire and it's clones are quite popular. There are other IDS's out there, but I don't know much about them, so the best I can reccommend on that front is to google for them.

[zenlunatic]

Not that I don't appreciate the *cough* (overused) jokes, but I am really not amused by the comments that say, "remove the box from the net." I am looking for some serious response here guys that would at least point me in the right direction regarding the issues i brought up. This is my first post to the security forums. I know that my question was vague, broad, and not easy to respond to, but I am very ashamed of the /. quality of some of these replies. Hopefull I didn't offend anyone. I'll look somewhere else with real solutions and not just jokes, although my resources are slowly dwindling (tired of reading the same usenet rants, etc...). Maybe their just aren't many folks out their who have a divers knowledge of coexisting security technologies.

[Beekster]

I have found the following site very helpful in getting started with iptables. It will generate a commented script that loads modules and sets the iptables up in the manner you specify.

Also for looking into iptables, check out this for the official doco. It's quite thorough.

As a starter, here's a sample of the kernel config you will need. This is from my router/firewall, so you are likely to not need the router option(s).

Code: Select all

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
# CONFIG_IP_ROUTE_NAT is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
CONFIG_IP_ROUTE_TOS=y
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_ROUTE_LARGE_TABLES is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set

#
#   IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_UNCLEAN=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_MIRROR=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
# CONFIG_IP_NF_NAT_LOCAL is not set
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM is not set
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set

Iptables needs to be compiled against your current kernel (ie with the /usr/src/linux symlink pointing to the right source).

[zenlunatic]

First and most obvious is to use a firewall.

Okay, fair enough. I sort of already had a vague notion that I should be running some sort of packet filter/firewall (any difference between those terms?). I do apprectiate your thoughtfull response, but what I was really trying to figure out is what the difference is between the few defacto packet filters that exist on Free Operating systems. The filters/firewalls that I am concerned with are:

• 1. iptables
  2. ipfw
  3. ipf
  4. pf

I already know that iptables is a improvement (mostly a rewrite though) of ipchains that was in the 2.2 linux kernel, although I didn't know about the stateless/stateful difference (thank you for clearing that up jondkent). I was also wondering if ipfilter and netfilter were considered full featured firewalls and/or packet filters or are they just the foundation of the other ones I listed.

My first reccommendation is to use the encrypted root filesystem as mentioned above.

This does sound like something I would like to implement, I am just confused as to which one to use. There seems to be a virtually unanomous consensus within the community which settles on encrypted loopback/crypto-API (are these the same thing) as the de facto method of encrypting an entire harddisk. Although I have heard others mentioned, and I am a naturally sceptical/curious person so I was just wondering how they all compare. Basically these are the systems which I have found to be offered to me for disk encryption (all links in first post):

• 1. Transparant Cryptographic File System - A maintained/current version of CFS . Actual File system.
  2. PPDD
  3. BestCrypt - Commercial
  4. VPDisk
  5. CryptFS - actual encrypted file system

I'm not really interested in Stegenographic file system's, although if anyone thinks this is a good choice for whatever reason do share. If I needed stegonography I would personally just look into hiding files in .mp3 or .jpeg etc... I don't see the use in an entire StegFS, do you?

The *actual* encrypted file systems seem iffy to me because it's not like using the tried and trusted ext or reiser. I attribute the popularity of encrypted loopback devices to this point alone. Also, if I had an encrypted file system how would I be able to connect my drive to another machine to recover files if the system got fried or something?

Second, I'd suggest storing as many of your logs as you can in some place other than the traditional /var/log/* because that is the first place attackers will look when they try to delete your logs to cover their tracks.

Are you suggesting I store this somewhere else on /, or on some sort of removable media?

Third, if you are able to, i'd recompile your kernel and take out kernel support for modules and turn your kernel from a modular one into a monolithic one.

I use a laptop and I have a usb floppy, usb usb-to-serial adaptar, and usb sound card (griffin imic used for line-in occasionally under ALSA) that I sometimes use. When I'm not using the external modem/soundcard I use the internals instead. Would I still be able to do this? Also, without modules would I be able to plug in my usb mouse on demand and remove it when needed, re-pluggin later if I need it? That's what I do now.

Hope those ideas help or give you some thought on what else you can do to secure your system. Also, if you're using a laptop, setting a boot passwd in the bios is useful. It won't stop someone determined enough to take your laptop apart to reset the bios, but the casual punk who doesn't know that much about computers will look at it in dazed confusion and give up.

Well I run a ppc laptop, so most of the conventional approaches won't work, such as generic boot disks. This machine is openfirmware based BTW.

The MIT program also includes some extra frills such as secure file deletion and harddisk free-space wiping.

Of you mean like shred?


Thanks for the thoughtful reply.

[zenlunatic]

I just thought I would let everyone know that I do not run a seperate firewall machine, nor do I plan on doing this anytime soon unless I get another box. I'm on dialup for christ sakes I just need protection for my laptop, although I am interested in also learning about the firewall rule writing, technology, etc...

Also, is it a good idea to run squid on the localhost, such as a laptop, from a technical perspective? Non-technically speaking, I would think this would be a way to entrap oneself, becuase if someone got a hold of those squid logs their they have all your URL GET requests, etc... Best way too ensure safety in this scenario would be to implent an encrypted system.

[rajl]

zenlunatic, I'll try and answer your questions as best I can.

On the topic of packet-filter firewalls, someone else above already answered those I thought, but i'll share what I know. i've only dealt with ipchains and iptables, so I won't comment on the other two for lack of experience. ipchains and iptables are both packet-filtering firewalls, but iptables is a stateful one, while ipchains is stateless. What this means is that iptables is able to keep track of whether connections are "new" (ie want to be made), "established" (already have been made), "related" ( a new connection that is being made because of an already established connection) or "invalid" (self explanatory). This makes iptables a lot more powerfule and useful than ipchains. Netfilter is just another name for iptables. I've never heard of ipfilter, before, so I can't comment on that. And yes, ipfilter/netfilter is considered a full-featured packet-filter firewall.

On encrypted file systems, it's a good idea, but i've never tried it so I can't give any more advice. I read the post above and it was quite detailed in it's instructions, so I would consider doing it that way.

As to the logs. Storing them on a seperate media that is removed and stored away on a regular basis is your best bet. But that's too resource intensive for a laptop user, unless you're turning your dialup connection into a webserver . My reccommendation is just in another folder on your harddrive. Perhaps hide it in /lib under a folder innocuously named to look like a library name of some sort. If you're feeling creative, change the name of the log as well from something like mail.info (which they can locate using the find command) to mserver.nfo or some other logical but non-standard name that would make it hard for someone else to find.

Taking out kernel module support. If you're going to use alsa per the gentoo documention or third-party vidcard drivers like Nvidia's, you have to use modules. No way around it for the time being that I am aware of. In the 2.6 kernel, alsa should replace OSS, so you won't need modules for that. I use a usbmouse on my desktop, and have it compiled into the kernel directly, no problem. Can remove and install it at will. I don't know about the usb floppy or serial adapter, but they should work too given the usb spec. My reccommendation is to compile a second test kernel, modify grub/lilo and give it a shot.

In regards to MIT's version of pgp, yes, those features are almost exactly like shred. I should warn you though that if you're using a tree based file-system like Reiserfs or XFS, shred is unreliable as it might not overwrite all copies of the file made (per the documentation). I don't know if MIT's implementation is any more reliable. My guess is no because the last release was done before Reiserfs and XFS became stable (yes, I know of XFS's lingering problems).

[zenlunatic]

I found some threads over at bsdforums.org and their seems to be a mutual hatred of the syntax in iptables. A lot of folks have made the point that every linux kernel has a changed packet filter. I only know of oen rewrite of the linux kernel packet filter myself. I also found out that you can run ipfw in linux. Is this worth doing?

Stay away from Linux-based firewalls. They are all crap. Not to mention, the firewall code changes with each new release of the kernel (ipfwadm --> ipchains --> iptables --> ???). The stateful checking in Linux firewall code is either non-existent or crap, and NAT support has only recently been added so it is very untested. The only thing going for Linux-based firewalls is the marketing hype behind the Linux "brand".

Stick to BSD for a firewall box. Use whichever BSD you know best. IPFilter runs on them all, so if you decide to change from Net --> Open --> Free --> BSD/OS, your rulesets will migrate with you. Or, you can use the firewall code that comes with the BSD you choose (PF on Open, IPFW on Free).

The firewall code on BSD is years ahead of where Linux is (or will be in the next few years). The syntax is clear, yet concise (without a dozen switches cluttering everything up). The stateful checking is truly stateful (IPF and PF can even to statefu lpacket inspection on non-stateful protocols such as UDP or ICMP). You can choose whether to use last-match or first-match wins rulesets. You can do filtering bridges (and can even remove the IP address from your bridge completely in OpenBSD). And a lot more.

So, to put together your own firewall box, definitely pick a BSD. This is just one more reason to avoid Linux.

Seems to be a lot of angry folks over at bsd forums

The problem with IPTables is that it is all new. The state engine is new. The NAT engine is new. The whole kit and kaboodle is new. It's all relatively untested. And it will all change again next year when kernel 2.6 comes out, just as it did with kernel 2.4 and kernel 2.2 and kernel 2.0 (see a pattern here). IPF and IPFW have gone through changes as well, but over the course of several years. They've been tested, improved, and hammered on. Doesn't get much better than that.

iptables bashing

[rajl]

I'd attribute those statements you've quoted mainly to the culture difference between BSD and linux. As I've never used BSD, much less BSD firewalls, I won't waste my time flaming them.

I've admittedly never done nat on iptables, but my friends who have so far have not complained about it being overly complex. The rulesets generally aren't that hard to use either from what they tell me. If you're not running any servers on your box, you're iptables firewall script is three lines long, as shown from the example code of my own firewall:

Code: Select all

/sbin/iptables -P INPUT DROP
/sbin/iptables -A INPUT -i eth0 -m --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A INPUT -i lo -j ACCEPT

The first line sets the default policy for the incoming connections to drop, which means all packets are dropped. The second line says to allow packets through the firewall that are part of connections you've established (say logging in to your mail server) or are part of connections related to already established connections coming in on my ethernet card, which is called eth0. If I wanted to accept connections on my other ethernet cards, I could change eth0 to eth1 or eth2. The third line accepts all packets on my loopback device. Some programs won't work (emerging perl is a prime example) if this third line is not present. Overall, not that complicated.

As for security, I know of no iptables security holes, though there may have been some in the distant past I'm not aware of. As for stability, iptables has always proved to be a solid and stable solution for myself and fellow linux users that I've talked to. The only complaints i've heard are from people who don't like to build firewalls at the command line and ask around for an iptables gui. As for charges of constant rewrites, yeah, it's true. Every time a new kernel comes out, the linux community includes a better firewall with it. Iptables is better than ipchains, which was better than it's predecesor. Given that the 2.4 kernel has been around for what, almost 3 years now, and the 2.2 kernel was around for how many years before that? You're looking at a major firewall rewrite/improvement every few years, which is on par with the BSD development schedule.

[kermitjunior]

Not that I don't appreciate the *cough* (overused) jokes, but I am really not amused by the comments that say, "remove the box from the net." I am looking for some serious response here guys that would at least point me in the right direction regarding the issues i brought up. This is my first post to the security forums. I know that my question was vague, broad, and not easy to respond to, but I am very ashamed of the /. quality of some of these replies. Hopefull I didn't offend anyone.

No offense. Sorry at my lack of help in that earlier post. I was busy watching a movie with my wife (her first viewing of The Matrix in prep for Reloaded).

You say that you don't think another box is necessary since you're on a laptop. You might still want to consider that, though. Assuming you only connect your laptop to the net at home, you could have a cheap kludger at home that does dial-on-demand and runs firewall/dhcpd.

My local pawnshop sells older pentium for about $50 US. And often computer stores will give you older stuff their customers don't want. Or check a recycling place nearby.

A separate box can, in effect, "disconnect you from the net" even if indirectly.

KJ

[zenlunatic]

No offense. Sorry at my lack of help in that earlier post.

No problem. Priorities first. It's just that I hear those jokes all the time in CS class, etc...

You say that you don't think another box is necessary since you're on a laptop. You might still want to consider that, though. Assuming you only connect your laptop to the net at home, you could have a cheap kludger at home that does dial-on-demand and runs firewall/dhcpd.

I had a desktop box which was a AMD 1600+ with 40GB HD, 256 RAM, 16MB Video, which is a lot more powerfull than my laptop (ibook). I sold that machine because all I used it for was playing CS, and that got a little out of hand

I will look into setting up something like you suggested. I know I don't need a massive machine for such a purpose. I will probably just dumpster dive for parts or something (thats how I built my first box ).

[Vancouverite]

Instead of anything specific I can recommend some general things. If you want to learn about firewalls get some good books and learn all the theory. This will give you marketable skills that you can apply to any packet filtering software. Then experiment with the BSD's and Linux until you discover what you like most. I have used netfilter, pf, ipf and ipfw and happen to like OpenBSD with pf the best but they are all solid if configured well. As for cryptography the encrypted root partition thread is probably the best thing to do. I set this up on an old 6GB drive I have to test it out and performance impact was minimal on my 1.4GHz Athlon. How secure the ciphers are is beyond me (I'm no cryptographer) but I think it's more than adequate.

BTW: I imagine there's tons of good books about all this on every p2p network in creation.

[zenlunatic]

What would be a good way to store my private key securely/

[puddpunk]

on a USB drive?

[mlynx]

You had a concern about an entire encrypted FS. I will add my $.02 in that regard. Your concern was that what would you do to recover information off the loopback if the laptop failed. It is actually fairly easy to recover using another machine to mount the loopback filesystem as long as you have the passphrase and the filesystem is relatively intact post hardware failure.