Hacking the Checkpoint UTM-1 Firewall for Performance

Checkpoint is a company that creates firewalls for computer networks.  Many years ago I decided to phase out our antiquated Cisco PIX firewalls and implement something more robust which could provide more services than just basic firewalling.  For the longest time, Checkpoint just sold the software which could be installed on anything.  The problem was that its software was already vastly more expensive than its competitors, and the hardware required to run the software wasn’t cheap either.

When they began to offer a full package, both hardware and software, I just about leapt at it after comparing it to several competitors including Cisco, Sonicwall, and Watchguard.  It cost the most, but provided the most features that I could actually use.  As time progressed, they released new software versions, added new features, and at the point of this writing – the firewall not only controls inbound and outbound connections, it also protects us from spam, viruses, worms, spyware, exploits, etc…  There isn’t much that can get past one of these things.

From the start, I did have some reservations regarding the UTM-1 450.  At its core, it was an Intel Celeron based system with 1gb of ram and a standard 80GB Seagate hard disk.  From my experience, Celeron CPU’s sucked, and putting a standard hard disk in such a critical network component added a point of failure that other systems which stored data in solid state memory didn’t have.  Still, the Linux based operating system was efficient enough to get the job done on the hardware we had.  In order to mitigate the drive failure, I went ahead and created “clusters” of these firewalls so that in the event one failed – the other could take over until I fixed the problem.

Over the years though, the ability of the hardware to support what the software could provide decreased dramatically. One of the most common tasks with these firewalls involves updating the rules and then copying or “pushing” those rules out to the firewalls.  That process which used to take a few minutes now took over 10 minutes.  Adding insult to injury, the level of resource starvation due to the software requirements would make all network traffic grind to a halt until the update completed.  I had looked into upgrading to the latest comparable offering from Checkpoint, but the pricing had me looking for other options…  I finally decided to do some research, and see if I could pull some greater performance from what I had.

I had gone into this thinking the biggest bottleneck of all was the CPU, and while it was a contributing factor, the main problem was that the standard hard drive couldn’t keep up with what Checkpoint’s R75.10 needed.

In order for the CPU to be recognized, I installed a fresh copy of R75 SPLAT (instead of the Appliance version).  The old CPU supported PAE (Physical Address Extension) but the new one did not, after tinkering with a stock 2.6.18 kernel to make it look like Checkpoint’s for a while, I decided to try the fresh installation route which worked splendidly.  Also, after cloning the hard disk to the SSD, I had to re-install the grub boot loader to the MBR.

Now from what I’ve read, the Nexcom-1042 system board behind the 450 has a hardware limit of 1gb of RAM.  I’m going to pick up a stick of 2gb DDR and see for myself though.  If I can get 2gb in there, I may be able to mount the /tmp/ directory on a ram drive instead of the SSD.

Some other tweaks I have made enable the management server to use certificate based authentication to access the root account on the enforcement points, which allows me to not only back up the management server via upgrade_export, but to also backup the individual enforcement points.  Lastly, I’ve been exploring the ‘etherlike’ mibs and have written a basic Nagios plugin for the UTM which allows me to calculate the current bandwidth (so I can generate and maintain historical data on the firewall’s bandwidth utilization via nagios).  I’m going to expand the plugin to provide even more data, none of the plugins currently available really gave me what I want.

Just to summarize what I did here:

  • Replaced the Celeron 1.5ghz CPU with a Pentium M 2.0ghz CPU.  On paper, you get .5ghz more clock speed and an extra 1MB of L2 Cache.  In reality there is a marginal boost in performance, the greatest bump comes from the extra L2 cache.
  • Replaced the standard Seagate 80gb 7200RPM IDE hard disk with a Crucial 64gb SATA SSD (running through a SATA to IDE adapter).  I needed to make a few tweaks to the kernel settings to optimize the SSD, but once done, it had some blazing performance.

As far as hard disk benchmarks are concerned:

 

Seagate:

  • Read: 63 MB/s
  • Write: 32 MB/s

 Crucial SSD:

 

  • Read: 89 MB/s
  • Write: 134 MB/s

That’s a 41% improvement in read speed, and a 318% percent improvement in write speed.  Those rule updates which took over 10 minutes and thrashed network connectivity now complete in under a minute, and there’s no impact on network connectivity… for about $150 worth of parts.

1.       Replaced the Celeron 1.5ghz CPU with a Pentium M 2.0ghz CPU.  On paper, you get .5ghz more clock speed and an extra 1MB of L2 Cache.  In reality there is a marginal boost in performance, the greatest bump comes from the extra L2 cache.

2.       Replaced the standard Seagate 80gb 7200RPM IDE hard disk with a Crucial 64gb SATA SSD (running through a SATA to IDE adapter).  I needed to make a few tweaks to the kernel settings to optimize the SSD, but once done, it had some blazing performance.

This entry was posted in Computers. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *