Using OpenBSD CARP and pfsync for inexpensive firewall/router redundancy
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.
[/Computers/Internet/Security/#carp_and_pfsync.html]
Comments (1)
GPG key
I have decided to start using my GPG key again to sign emails and
such. It's a good thing to use encryption and digital signature technology.
Consequently, I've gone ahead and posted my key
here
[/Computers/Internet/Security/#gpg_key_info.html]
Comments (0)
Using multiple physical machines behind a single NAT IP address
So you have just one IP address and a bunch of machines behind NAT.
You've got port redirection working so your interal webserver behind
the firewall is serving pages. But now you've got a second box that
you need to host content on. Perhaps you have need to have a separate
webserver running mod_perl and one running php. Or perhaps you've got
(God forbid) an IIS box. And you don't want to redirect alternate
ports. Here's away to have multiple webservers behind a single
external IP address all running on Port 80.
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
[/Computers/Internet/Security/#apache_proxy.html]
Comments (0)
|