How to Upgrade and Why You Might Want to.
If you are running a version of Gibraltar older than 0.99.8a, you should
consider upgrading. A variety of buffer management errors in daemons and
libraries were corrected in 0.99.8a and it is difficult to know for
certain whether older versions might be remotely vulnerable to attack.
Reasons to Consider Upgrading to 0.99.4
- Larger and dynamically-resizable ramdisks.
- More/newer software. (FTP and web proxies, tools, utilities, etc.).
See the Gibraltar changelog
- Better "save-config" script and more convenient save format (tar).
- Web browser (lynx) for reading HTML docs in /usr/doc on the firewall.
Additional Reasons to Consider Upgrading to 0.99.5
- More/newer software. (ntpd, mtools, hdparm, ddclient, FreeSWAN, etc.).
See the Gibraltar changelog
Additional Reasons to Consider Upgrading to 0.99.6a
- Ability to restore /etc filesystem larger than 4MB from floppy.
- More save-config destinations (not just to floppy).
- Some anti-spam support (sanitizer, spamassassin and razor).
- More/newer software. (iptstate, bridge-nf, ntop, dhcp3, sharutils, etc.).
See the Gibraltar changelog
- More protocol-specific NAT modules (H.323, PPTP, IRC, GRE).
- Supports Variation #4 (a filtering
bridge physical firewall).
Additional Reasons to Consider Upgrading to 0.99.7a
- Has ability to save config on USB drive instead of floppy.
- Fixes the kernel NIC driver information leak described in
http://www.kb.cert.org/vuls/id/412115. If one of these
NIC drivers shows up when your run "
lsmod
", you
should upgrade:
3c501, 3c505, 3c507, 3c523, 3c527, 7990, 8139too, 82596, 8390, a2065,
am79c961a, ariadne, at1700, atarilance, atp, axnet_cs, bagetlance, de600,
de620, declance, depca, eepro, eexpress, epic100, eth16i, fmv18x,
fmvj18x_cs, hp100, lance, lasi_82596, lp486e, ni5010, ni52, ni65, ray_cs,
seeq8005, sgiseeq, sk_g16, smc9194, sun3_82586, sun3lance, via-rhine,
wavelan, xirc2ps_cs, xircom_tulip_cb, yellowfin, znet.
- Has L2TP (Layer 2 Tunnelling Protocol).
- Supports HTB queuing discipline (for rate limiting).
- Updated FreeS/WAN allows IPSEC through NAT.
- Another security bug in DHCP server fixed.
- Glibc has been patched against a bug (which probably wasn't remotely
exploitable) but as a consequence, the extra layer of protection
provided by "libsafe" has been removed (in this release only).
- See the Gibraltar changelog
for a complete list.
Additional Reasons to Consider Upgrading to 0.99.8a
- Has the most recent OpenSSH and SSL patches.
- Has libsafe protection once again (0.99.7a did not).
- Has the linux 2.4.22 kernel compiled to support upto 4GB of RAM.
- Has tunable iptables state timeouts (see /proc/sys/net/ipv4/netfilter/*).
- Rotates and compresses log files at 500KB so /var ramdisk shouldn't fill.
- Has updated pptpd which supports PPPoATM and PPPoE.
- Has updated FreeS/WAN (ipsec) package.
- Has clamav (an opensource email virus scanner).
- Has snort 2.0 (which claims to be very much faster than 1.x).
- Has ebtables (like iptables but at the ethernet level).
- Does not log rejected packet info directly to the console.
- See the Gibraltar changelog
for a complete list.
Additional Reasons to Consider Upgrading to 1.0
- Probably none! It is essentially the same as 0.99.8a but includes
the commercial GUI (which requires a license key to activate and
which I don't think you can use with the LFW anyway).
Additional Reasons to Consider Upgrading to 1.1
- Has Linux kernel 2.4.23 (fixes one of two privilege escalation bugs
which are not believed to be remotely exploitable).
- Has new kernel patches from
the PAX project to make exploiting buffer overflows harder.
- Has winbind (for PAM authentication against Windows 2000 domains).
- Has smbclient.
- Has OpenVPN.
- Has a much improved automatic upgrade script.
- See the Gibraltar changelog
for a complete list.
No Reason to Consider Upgrading to 1.2
- Only the (unused) commercial GUI has changed between version 1.1 and 1.2.
Additional Reasons to Consider Upgrading to 2.0
- Has a patching mechanism so, if necessary, it may be possible to
upgrade some software without requiring a new Gibraltar version
(and the associated reboot/downtime that entails).
- Has Linux kernel 2.4.26 (which also fixes the mremap privilege escalation
bug, though it is not known to be remotely exploitable).
- Adds support for BCM5700 network cards.
- New "tcpdump" supports capture files > 2GB.
- New "ntop", more "iptables" modules, and lots of other package upgrades.
- See the Gibraltar changelog
for a complete list.
Additional Reasons to Consider Upgrading to 2.1
(Note: Some performance issues remain to be solved for LFW configuration.)
- Has FreeSWAN bugfix (may not be relevant to use at UW).
- Has Linux Kernel 2.4.27 and some additional drivers.
- Has a SIP proxy for VOIP.
- Has fprobe and flow-tools for generating/reporting netflows.
- Has newer "iptraf", "ntop", and various other things.
- See the Gibraltar changelog
for a complete list.
Additional Reasons to Consider Upgrading to 2.2
- Performance issues of version 2.1 have been solved.
- Has ifrename package to specify explicitly (in /etc/iftab) which NIC becomes eth0 etc.
- Has OpenSWAN in place of FreeSWAN (FreeSWAN development stopped/forked).
- Has Linux Kernel 2.4.30, better hardware detection and some new drivers.
- Has support for L2TP (not yet tested/documented with LFW).
- Has TCP window tracking (you may notice new syslog messages). See
THIS and
THIS
for more details.
- Many other program packages upgraded.
- See the Gibraltar changelog
for a complete list.
No Reason to Consider Upgrading to 2.2a
- 2.2a adds only a small fix to an IPSEC configuration not used by the LFW.
Because very little changed from 2.2, it should work as well as 2.2.
Additional Reasons to Consider Upgrading to 2.3
- Has patches to allow better PPTP authentication options (details soon).
- Many other program packages upgraded.
- See the Gibraltar changelog
for a complete list.
Additional Reasons to Consider Upgrading to 2.4.1
- Simultaneous PPTP (VPN) client limit raised from 100 to 1024.
- Has Snort version 2.3.2 and the "oinkmaster" snort-rule upgrade package.
- Has IMQ patch to allow better traffic shaping.
- Slight speed increase (on the order of 5% +/- 5%).
- Offers more CPU stats (vmstat -s).
- Has tools for anonymous network usage (not recommended at UW).
- Has "ulogd" for more efficient "iptables" logging (disabled by default).
- Has a new OpenSwan version (2.4.0) which, unfortunately, is not
100% backwards-compatible with older OpenSwan versions and causes
them to transparently restart every minute for about 2.5 days and then
stop working until the older system is rebooted. If you use
ipsec tunnels between firewalls you may find you need to either
upgrade all your firewalls to a new Gibraltar at the same time or
at least apply OpenSwan patches to your older firewalls (if they
aren't too old). A patch for OpenSwan on Gibraltar 2.3 is
available at:
http://www.gibraltar.at/getPatch.php?version=2.3&patch=openswan_2.4.0-1-all-3.gib.
(The patch can be applied to a running 2.3 firewall by putting it in
/etc/gibraltar/patches/openswan_2.4.0-1-all-3.gib
and running
"patchme /etc/gibraltar/patches/openswan_2.4.0-1-all-3.gib
")
- Many other program and library packages upgraded.
- See the Gibraltar changelog
for a complete list.
Additional Reasons to Consider Upgrading to 2.5
- Better logfile rotation if/when /var ramdisk fills.
- Can be set to reboot if enough space can not be freed on /var (improving logging at the expense of uptime).
- Upgrades OpenSWAN to 2.4.6 improving NAT-traversal and pluto memory use
but see same caveat about backward incompatibility as 2.4.1.
- Changes default action in (unlikely) event of kernel panic to: reboot.
- Updates OpenVPN to 2.0.9 and ntop to 3.2.
- Many other program packages upgraded.
- See the Gibraltar changelog
for a complete list.
How to Upgrade
Preferred Method
Upgrading is probably most easily accomplished by following the steps
in Obtaining and Configuring a new Gibraltar
(including running "uw-setup
" and answering all the
questions) and then overlaying a few essential files from your old system and
then running uw-setup again as "uw-setup -n
".
Unless you have specifically created others, the only files you need
to carry forward are:
/usr/local/sbin/tables*
/etc/aliases
/etc/network/interfaces
/etc/ssh/sshd_config
/etc/ssh/ssh_host*
/etc/ipsec.conf
/etc/ipsec.secrets
/etc/pptpd.conf
/etc/ppp/pptpd-options
/etc/ppp/chap-secrets
/etc/syslog.conf
You can carry these files forward in any way which is convenient. One way
is to temporarily put your old configuration floppy in your new system and use
the "uw-restore
" command to extract the files above from
the floppy. (If your new Gibraltar system doesn't have a working "uw-restore",
download the latest "uw-setup" and run
"uw-setup -n
" to obtain it.) Once you've carried
forward the old files,
be sure to run "uw-setup -n
"
(to make sure any version-specific changes are applied to the files you've just
carried forward)
and then run "save-config" and reboot (since you'll want to
make sure your configuration will reboot properly anyway).
If you have created/modified files not listed above and you'd like
them carried forward automatically by "uw-restore", you can list them, one per
line, in "/usr/local/bin/uw-restore.local
" and, those files will
be added to the default list. (They must, however, be listed in the file by
their path relative to the "/etc
" directory with no leading slash
or dot, since that is how they are archived on the floppy--look at the
beginning of "/usr/local/bin/uw-restore
" for examples and other
options).
If you want to minimize downtime, you can prepare your new Gibraltar
configuration floppy on a spare system and then just swap the new CDROM and
floppy into the production system. I did an upgrade (to a system without
keyboard or display) this way and had just 2 minutes of downtime.
When you run "uw-setup" on a spare system and give it
the production system's IP address, be sure the spare system is not
connected to the net or it will conflict with the production system!
It is possible to have just seconds of downtime by bringing up a spare
system (off the net as above) and then quickly transfering the network
connection to the spare system and immediately running
"arp-push
" on it. Under the right conditions it is
possible to upgrade a firewall without disrupting its clients this way.
(One can do this twice to wind up using the original hardware). Preserving
client connections requires both quickly making the switch and having
firewall rules which (at least initially) accept the client's traffic in the
absense of the connected state (e.g. bidirectionally).
New Alternate Method: Automatic Upgrade
Upgrading to Gibraltar version 1.1 (or newer) can also be accomplished
by simply booting the new Gibraltar with the old configuration disk
and then running the latest uw-setup -n
.
Gibraltar will automatically handle:
- All files you (or uw-setup) HAVE NOT modified which HAVE changed in
the new release.
- All files you (or uw-setup) HAVE modified which HAVE NOT changed in
the new release.
- All files you (or uw-setup) HAVE NOT modified which HAVE NOT changed in
the new release.
- All files you (or uw-setup) created in "
/etc/
".
Files which you (or uw-setup) HAVE modified which HAVE ALSO changed in the
new release will be carried forward unchanged and the new version will be
placed in a similarly named file (with a dash and the new gibraltar version
number appended). It is then left to you to manually reconcile those
files (and delete the similarly-named new versions when you're done with
them).
A transcript of the significant details of the automatic upgrade will
be written to "/etc/gibraltar/update-#.#_to_#.#.log
so you need not worry if something scrolls off the screen too fast.
As in the "preferred method" above (and after
manually reconciling all files not handled automatically)
be sure to obtain and run the latest
"uw-setup -n
" after the upgrade.
Old Alternate Method
Another way to upgrade is to
Obtain and Configure a new Gibraltar as
above and then follow the steps in
Restoring a Firewall From Just a Saved Tables File. This method is
more awkward to do on a spare system without disrupting the running
firewall so it is recommended only for installations where keeping downtime
to the absolute minimum is not essential and you can do the work on the
real firewall. Still, it should be possible to accomplish an upgrade this
way with less than 5 minutes of downtime.
Corey Satten
Email -- corey @ u.washington.edu
Web -- http://staff.washington.edu/corey/
Date --
Mon Jan 28 12:27:22 PST 2008