I recently installed Linux Mint (ubuntu with some goodies) on a laptop and wanted an encrypted whole disk. In order for this to be truly secure, you need encrypted swap. Well most of the HOWTOs for encrypting swap use a randomized key. This breaks hibernate to disk for laptops because the linux kernel has no way to decrypt a randomized cipher (of course). So I referenced a separate howto and combined the two approaches. I can now hibernate to disk using an encrypted swap partition that is protected with a passphrase in the same as way as root and home partitions.

It should be apparent this howto is non-trivial.  The config file changes I supply in it are in diff -u format so this is deliberately written for a technical audience. My research indicates that there is some interest in getting this into distributions in a more elegant fashion, but that kind of deep integration takes time. I needed something that works for me now.

Anyway, here’s the link in the Linux Mint user forums: ]]> http://www.scottharney.com/2009/09/17/linux-with-encrypted-root-and-swap-with-working-hibernate-to-disk/feed/ 0 http://www.scottharney.com/2004/03/30/using-openbsd-carp-and-pfsync-for-inexpensive-firewallrouter-redundancy/ http://www.scottharney.com/2004/03/30/using-openbsd-carp-and-pfsync-for-inexpensive-firewallrouter-redundancy/#comments Tue, 30 Mar 2004 23:28:00 +0000 scotth http://www.scottharney.com/htdocs/wordpress/?p=71 Enterprise network admins are probably familiar with Cisco’s HSRP which allows for router redundancy and VRRP for firewall redundancy. This article describes a way to achieve the same thing using features in the upcoming OpenBSD 3.5 release . Other commercial firewalls certainly have similar capability. However, OpenBSD’s feature set is becoming rather compelling.

Smaller businesses can certainly find value in such an approach, keeping their network available and secure at a fraction of the cost. Evening paying an outside consultant for installation and ongoing support would be cost effective. Deploy something like this and things remain comfortable for your cisco-trained network admins.

All of this of course reminds me that I really need to schedule some time to upgrade my own OpenBSD firewall.

What you need is a reverse inbound proxy established on your firewall.
Apache with mod_proxy built and
enabled does the trick.

First and foremost you need to have your DNS sorted out. I have both
external and internal DNS servers. Bind 9 can do
this with “views” though I personally have a preference for setting up
djbdns. If you do not have
an internal DNS for your domains then you’ll need to reference your
internal boxes by IP address in your apache configuration (see below).

The next thing to do is fix your firewall. You need to install apache.
mod_proxy should come with it. You need to stop redirected port 80
inbound in your NAT (aka IP Masq) configuration since the firewall
will now answer on Port 80. Since I have internal DNS servers, I
also made sure my firewall’s /etc/resolv.conf pointed to the
internal DNS server.

Now you set up Apache on your firewall. Just do a basic configuration.
Here’s the magical lines snipped from httpd.conf

LoadModule proxy_module       libexec/apache/libproxy.so
AddModule mod_proxy.c

NameVirtualHost your.external.ip.address

<VirtualHost your.external.ip.address>
   ServerAdmin webmaster@yourwebsite.net
   ServerName www.yourwebsite.net
   ProxyPass / http://www.yourwebsite.net/
   ProxyPassReverse / http://www.yourwebsite.net/
   ErrorLog /var/log/apache/yourwebsite.net/error_log
   TransferLog /var/log/apache/yourwebsite.net/access_log
<VirtualHost>

Since the internal DNS server has a local (ie 192.168.x.x) address
for “www.yourwebsite.net”, requests to that NameVirtualHost go
to the appropriate internal box. And it need not be running
apache. Anything that speaks http will be transparently proxied.

If you don’t do internal DNS you’d replace
“http://www.yourwebsite.net” with something like “http://192.168.5.80″
where that is the IP of the internal server that you want to answer
for www.yourwebsite.net.

Note that you can also do SSL https connections this way. The key is
that you need to have your SSL certs and keyfiles on the firewall. The
firewall would then speak standard http on port 80 to the internal box
The config looks like this:

<VirtualHost your.external.ip.address:443>
   ServerAdmin webmaster@yourwebsite.net
   ServerName secure.yourwebsite.net
   ProxyPass / http://secure.yourwebsite.net/
   ProxyPassReverse / http://secure.yourwebsite.net/
   SSLEngine on
   SSLCertificateFile /path/to/certfile
   SSLCertificateKeyfile /ditto/for/keyfile.key
   ErrorLog /var/log/apache/secure.yourwebsite.net/error_log
   TransferLog /var/log/apache/secure.yourwebsite.net/access_log
</VirtualHost>

As you can see, it really helps to have internal DNS set up.
That makes things easier and allows you to have NameVirtualHosts
on your internal boxes. You could just to IP based VirtualHosts
internally configuring multiple 192.168.x.x IPs on your internal
servers.

I’m sure you can imagine some very useful ways of doing this.
It makes a test and development environment easy. You can stand up
a replacement website without going through the hastle of waiting for
public DNS to “catch up”.

Obviously there are security considerations. I won’t go into a major
discussion about that here except to say that you need to think about
it. For my needs, this increased my security posture because I could
move Win2000 machines with many potential vulnerabilities behind the
firewall and reduce exposure to just IIS and cross-site scripting
issues. That’s still plenty to worry about, but better than having,
say, MSSQL outside your firewall)

Another implication of this is that your logging of website
connections changes. All that your internal boxes will ever log now
are connections from the firewall. So those logs are useless for
tracking site traffic, etc. But all your hits are logged –
separately the way I configured it — on the firewall itself. Just make
sure you make those log subdirectories manually before restarting
apache because apache won’t create them. The master apache error log
will report this, of course.

References:
1

2
3