Sample Link Post

This theme supports link posts, made famous by John Gruber. To use, just add

link: http://url-you-want-linked
to the post’s YAML front matter and you’re done.

If you ran Check Point FireWall-1 on SunOS or Solaris, you probably remember this screen:

This is a screen capture from fwui, the management interface for FireWall-1. Actually FireWall-1 2.0 and 2.1 looked like this too.

Meanwhile if you ran the management interface on Windows, you were presented with something like this:

You could actually run the firewall on Windows NT as of 2.1, though it took until 2.1c until it was reasonably stable.

Actually you could run something that looked like the Windows UI on Solaris with Motif, which Check Point charged extra for. Eventually the Motif and the OpenLook GUI were deprecated and what we now refer to as SmartDashboad only runs on Windows.

And, of course, there are far more GUI clients these days–about a dozen or so if I remember correctly. But then again, the product does so much more today than it did back in the mid 1990s.

And yes, I remember those days quiet fondly.

For those of you who never had to work with Check Point FireWall-1 4.1 and earlier, you're lucky you likely never EVER had to use putkeys.

The fw putkey was used to establish authentication between the Management and Firewall modules. The problem was: the authentication would frequently break. Especially in larger, distributed environments. Often for reasons that no one outside of a few developers in Tel Aviv never fully understood.

The eventual replacement for fw putkey was SIC, which was added in FireWall-1 NG (5.0). It is based on certificates and is way easier to set up. It's also far less prone to random breakage. 

The following classic article is presented for nostalgia purposes only. Hopefully no one in their right mind still needs this article, which was very popular on my FireWall-1 FAQ back in the day. It was the collective wisdom of my peers and my own experience as of around 2000 or so.

Can't Get Putkeys to Work


I can't get my putkeys to work ir I can't keep them working. What am I


One thing that I've always done on habit with my firewall systems is to

make sure all IPs on both the management and firewall are resolvable to
hostname within the system's local host file and that the systems are
to look at the local hosts file before looking to DNS. As a
result, the
number of issues I personally have had with putkeys in any
systems I have
personally set up have been minimal. I would suggest doing
this before redoing
all your putkeys. Also, double-check to make sure the time on your management
console and firewall module have their time synchronized (relative to GMT).

One known issue: If you are using skey authentication on versions of
prior to 4.0 SP5, there is an issue whereby the authentication
can get out
of sync. Either use fwn1 (which works on systems 4.0 SP4 and
earlier) or
use none authentication. For more information, see: Failed

to Install Security Policy on fw62bs01: Unauthorized action.

If you have to redo your putkeys, there are three methods one can use

to do putkeys, one of which usually works:

Putkey with all IPs

A trick I have found that works is to use all possible IP addresses in
putkey command. For example, if my management console had only one IP
and my firewall had several IPs:


My putkey from the management console to the firewall would look like


fw putkey

And my putkey from the firewall to the management console would be:

fw putkey

In a step-by-step manner, here is what you would do:

  1. fwstop both the management and firewall modules

  3. On the FireWall, type: fw putkey

  5. On the management console, type: fw putkey

  6. fwstart the management console

  8. fwstart the firewall module

Forcing the nodename IP

When performing the authentication necessary for remote management, FireWall-1

will attempt to use the 'nodename IP' to communicate between the systems.

If the nodename IP does not exist or is not reachable from all systems,
causes putkeys to not work. A way to get around this problem is to
use putkey
in the following manner:

fw putkey -n local-ip remote-ip

The "local ip" here depends on which interface you will need to talk
to see the remote system. The "remote ip" will be the IP address that
closest to you.

For instance, if your firewall had the following interfaces:


And your management console had the following interfaces:


On the firewall console, you would type:

fw putkey -n

On the management console, you would type:

fw putkey -n

In a step-by-step manner, here is what you would do:

  1. fwstop both the management and firewall modules
  2. On the FireWall, type: fw putkey -n
  3. On the management console, type: fw putkey -n
  4. fwstart the management console
  5. fwstart the firewall module

Touching all putkey-related files

Karim Ismail makes the following

suggestion: Simply "touch" the following files (i.e. use the Unix/IPSO
command) before performing the putkey command:





The file

Sometimes, you will need to add IP addresses to $FWDIR/lib/
for whatever reason, FireWall-1 is not seeing the IP address it
is hearing
the connection from as the appropriate type of host (either
as a remote
firewall module or a management console). In any case, you
can insure that
FireWall-1 is handling this correctly by editing $FWDIR/lib/

Add all the IPs of the remote hosts you wish to authenticate with

in a new line (above the MASTERS, CLIENT, and * lines) and force the authentication

that will be used for these IPs to the appropriate authentication scheme

(fwn1, fwa1, skey).

a.b.c.d, e.f.g.h : */fwa1
MASTERS :stat,getkey,gettopo/none opsec/fwn1 */fwa1
CLIENT  :load,db_download,fetch,log/fwa1   opsec/fwn1

*       :stat,getkey,gettopo/none
opsec/fwn1 */fwa1

If you edit this file, stop and start FireWall-1. For more information 
on, see: Failed to Install Security Policy
on fw62bs01: Unauthorized action

Flushing All Putkey-Related Files

There are some cases where even this does not work. Here is a procedure

developed by Lance Spitzner (which

I have slightly modified):

On the Management Module

  •  fwstop
  •  Backup the following files by copying them to <filename>.old
    • $FWDIR/database/authkeys.C
    • $FWDIR/database/opsec_authkeys.C
    • $FWDIR/conf/fwauth.keys
    • $FWDIR/conf/serverkeys.*
  • Remove the above files
  • Confirm that $FWDIR/lib/ is using the same authentication
    the remote modules (fwa1 or skey).
  • Make sure /etc/hosts has an entry for the remote module(s).

On the Remote Module

  • fwstop
  • Backup the following files by copying them to <filename>.old
    • $FWDIR/database/authkeys.C
    • $FWDIR/database/opsec_authkeys.C
    • $FWDIR/conf/fwauth.keys
    • $FWDIR/conf/serverkeys.*
  • Remove the above files
  • Confirm that $FWDIR/lib/ is using the same authentication
    the management module (fwa1 or skey).
  • Make sure /etc/hosts has an entry for the management module.

On the Management Module: fw putkey -p <password> -n <local IP>

On the Remote Module: fw putkey -p <password> -n <local IP>

On the Mangement Module: fwstart

On the Remote Module: fwstart

That's it!  If that did not do the trick, ensure all Network Objects

in Rule Base match /etc/hosts file and fw putkey IP addresses.  Repeat

steps above.

If you don't want to fwstop the firewall modules

I personally have had success sometimes simply killing and restarting fwd,

which is not as drastic as restarting FireWall-1, but can make certain
unavailable. However, Bradley

Filmer says this method does not require fwstopping the firewall module.

On the firewall module, edit $FWDIR/database/authkeys.C and remove everything

between the opening parenthesis "(" and the closing parenthesis ")". Redo

the putkeys using one of the methods above (he suggests using the -n method,

but only use that method if you have to). On the management console, do
same thing except perform an fwstop and fwstart afterwords.

As a Last Resort

Sometimes, you will need to reboot either the management console, firewall

module, or both to make putkeys work. Don't necessarily have an explanation

for it. If you reboot one but not the other, execute an fwstop; fwstart
the other box.

Even after that, it may not work either. What you can do is disable
authentication entirely. Note that this is not entirely recommended
in all
cases, but if you need to get it working quickly, this trick will
work. Edit as above on all involved systems and
use "none" as
the authentication scheme. Stop and start FireWall-1. You
will no longer
have any more troubles with putkeys between these systems
as you have effectively
reduced the authentication to IP only.

I decided to move PhoneBoy's Security Theater off of Wordpress onto Posthaven

On the plus side, it's one less instance of Wordpress to maintain. On the minus side, I had to copy/paste the old articles in since there is no way to import Wordpress as of yet. But it was under 100 articles and it was kind of nice to see my thoughts on security from the last several years again.

The reality is, the threats haven't changed. We've had to evolve the tools in order to address increasingly complex threats. You can look at Check Point's own product evolution to get a sense of that.

Also, the basics haven't changed. A lot of security risks can be sufficiently mitigated by properly segmenting your networks, using sufficiently complex passwords that are unique, proper monitoring of the logs of your security devices, and keeping your software up-to-date with the latest security patches. 

Earlier this week, I hung out with Jeremy Kaye, one of our in-house compliance experts at Check Point:

While I've been doing InfoSec for a while, or at least working in companies that sell InfoSec products, compliance isn't something I've had a ton of direct experience with. Sure, Check Point customers used our products to help meet various compliance regulations, but until Check Point acquired DynaSec in 2011, there wasn't a team inside Check Point dedicated to this topic.

While we had some technical challenges with the Google+ Hangout itself (and it was the first one we did at Check Point), I think the conversation with Jeremy went fairly well. The questions I asked where ones I've always wanted answers to. Like, what good is compliance? Why does it seem like compliance is in the eye of the auditor? Why so many regulations anyway?

The big takeaway for me from this conversation is that security should drive your compliance efforts, not the other way around. Because chances are, if you have a strong information security program in place already, compliance is pretty straightforward, no matter which regulations you have to comply with.