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

  1. Larger and dynamically-resizable ramdisks.

  2. More/newer software. (FTP and web proxies, tools, utilities, etc.). See the Gibraltar changelog

  3. Better "save-config" script and more convenient save format (tar).

  4. Web browser (lynx) for reading HTML docs in /usr/doc on the firewall.

Additional Reasons to Consider Upgrading to 0.99.5

  1. More/newer software. (ntpd, mtools, hdparm, ddclient, FreeSWAN, etc.). See the Gibraltar changelog

Additional Reasons to Consider Upgrading to 0.99.6a

  1. Ability to restore /etc filesystem larger than 4MB from floppy.

  2. More save-config destinations (not just to floppy).

  3. Some anti-spam support (sanitizer, spamassassin and razor).

  4. More/newer software. (iptstate, bridge-nf, ntop, dhcp3, sharutils, etc.). See the Gibraltar changelog

  5. More protocol-specific NAT modules (H.323, PPTP, IRC, GRE).

  6. Supports Variation #4 (a filtering bridge physical firewall).

Additional Reasons to Consider Upgrading to 0.99.7a

  1. Has ability to save config on USB drive instead of floppy.

  2. 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.

  3. Has L2TP (Layer 2 Tunnelling Protocol).

  4. Supports HTB queuing discipline (for rate limiting).

  5. Updated FreeS/WAN allows IPSEC through NAT.

  6. Another security bug in DHCP server fixed.

  7. 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).

  8. See the Gibraltar changelog for a complete list.

Additional Reasons to Consider Upgrading to 0.99.8a

  1. Has the most recent OpenSSH and SSL patches.

  2. Has libsafe protection once again (0.99.7a did not).

  3. Has the linux 2.4.22 kernel compiled to support upto 4GB of RAM.

  4. Has tunable iptables state timeouts (see /proc/sys/net/ipv4/netfilter/*).

  5. Rotates and compresses log files at 500KB so /var ramdisk shouldn't fill.

  6. Has updated pptpd which supports PPPoATM and PPPoE.

  7. Has updated FreeS/WAN (ipsec) package.

  8. Has clamav (an opensource email virus scanner).

  9. Has snort 2.0 (which claims to be very much faster than 1.x).

  10. Has ebtables (like iptables but at the ethernet level).

  11. Does not log rejected packet info directly to the console.

  12. See the Gibraltar changelog for a complete list.

Additional Reasons to Consider Upgrading to 1.0

Additional Reasons to Consider Upgrading to 1.1

  1. Has Linux kernel 2.4.23 (fixes one of two privilege escalation bugs which are not believed to be remotely exploitable).

  2. Has new kernel patches from the PAX project to make exploiting buffer overflows harder.

  3. Has winbind (for PAM authentication against Windows 2000 domains).

  4. Has smbclient.

  5. Has OpenVPN.

  6. Has a much improved automatic upgrade script.

  7. See the Gibraltar changelog for a complete list.

No Reason to Consider Upgrading to 1.2

Additional Reasons to Consider Upgrading to 2.0

  1. 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).

  2. Has Linux kernel 2.4.26 (which also fixes the mremap privilege escalation bug, though it is not known to be remotely exploitable).

  3. Adds support for BCM5700 network cards.

  4. New "tcpdump" supports capture files > 2GB.

  5. New "ntop", more "iptables" modules, and lots of other package upgrades.

  6. 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.)

  1. Has FreeSWAN bugfix (may not be relevant to use at UW).

  2. Has Linux Kernel 2.4.27 and some additional drivers.

  3. Has a SIP proxy for VOIP.

  4. Has fprobe and flow-tools for generating/reporting netflows.

  5. Has newer "iptraf", "ntop", and various other things.

  6. See the Gibraltar changelog for a complete list.

Additional Reasons to Consider Upgrading to 2.2

  1. Performance issues of version 2.1 have been solved.

  2. Has ifrename package to specify explicitly (in /etc/iftab) which NIC becomes eth0 etc.

  3. Has OpenSWAN in place of FreeSWAN (FreeSWAN development stopped/forked).

  4. Has Linux Kernel 2.4.30, better hardware detection and some new drivers.

  5. Has support for L2TP (not yet tested/documented with LFW).

  6. Has TCP window tracking (you may notice new syslog messages). See THIS and THIS for more details.

  7. Many other program packages upgraded.

  8. See the Gibraltar changelog for a complete list.

No Reason to Consider Upgrading to 2.2a

Additional Reasons to Consider Upgrading to 2.3

  1. Has patches to allow better PPTP authentication options (details soon).

  2. Many other program packages upgraded.

  3. See the Gibraltar changelog for a complete list.

Additional Reasons to Consider Upgrading to 2.4.1

  1. Simultaneous PPTP (VPN) client limit raised from 100 to 1024.

  2. Has Snort version 2.3.2 and the "oinkmaster" snort-rule upgrade package.

  3. Has IMQ patch to allow better traffic shaping.

  4. Slight speed increase (on the order of 5% +/- 5%).

  5. Offers more CPU stats (vmstat -s).

  6. Has tools for anonymous network usage (not recommended at UW).

  7. Has "ulogd" for more efficient "iptables" logging (disabled by default).

  8. 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")

  9. Many other program and library packages upgraded.

  10. See the Gibraltar changelog for a complete list.

Additional Reasons to Consider Upgrading to 2.5

  1. Better logfile rotation if/when /var ramdisk fills.

  2. Can be set to reboot if enough space can not be freed on /var (improving logging at the expense of uptime).

  3. Upgrades OpenSWAN to 2.4.6 improving NAT-traversal and pluto memory use
    but see same caveat about backward incompatibility as 2.4.1.

  4. Changes default action in (unlikely) event of kernel panic to: reboot.

  5. Updates OpenVPN to 2.0.9 and ntop to 3.2.

  6. Many other program packages upgraded.

  7. 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:

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