I have been told that there are multiple threads on the forum concerning the OPSEC
response with Checkpoint NG. Here are the procedures that we have verified to work
with NGFP2. The "authenticated" procedure is for clear text OPSEC commands and the
"authenticated and encrypted" procedure will use ssl encryption for the OPSEC commands.
Authenticated and encrypted
1. Add the following lines to fwopsec.conf on the firewall:
sam_server auth_port 18183
sam_server auth_type ssl_opsec
lea_server auth_port 18184
2. Restart the firewall using fwstop and fwstart- this will force a configuration
reload.
3. From the firewall, run the following command replacing <Sensor_IP> with a valid
address for the sensor:
fw putkey -OPSEC -ssl <Sensor_IP>
4. From the sensor's directory (C:\Program Files\ISS\issSensors\network_sensor_1 or
appropriate directory) run the following command replacing <Firewall_IP> with a valid
firewall management server address:
opsec_putkey -ssl <Firewall_IP>
You should see a message that the key was saved to a file.
5. Create a response policy with a valid management server address (same as
<Firewall_IP> from above,) set communication to Authenticated and Encrypted, and set
the rest of the options as appropriate to your environment. Apply this policy to the
sensor.
6. Create a policy with OPSEC enabled for appropriate events. Apply this policy to
the sensor.
7. Stop and start the sensor from the WGM or Site Protector.
Authenticated
1. Add the following lines to fwopsec.conf on the firewall:
sam_server auth_port 18183
sam_server auth_type auth_opsec
lea_server auth_port 18184
2. Restart the firewall using fwstop and fwstart- this will force a configuration
reload.
3. From the firewall, run the following command replacing <Sensor_IP> with a valid
address for the sensor:
fw putkey -OPSEC <Sensor_IP>
4. From the sensor's directory (C:\Program Files\ISS\issSensors\network_sensor_1 or
appropriate directory) run the following command replacing <Firewall_IP> with a valid
firewall management server address:
opsec_putkey <Firewall_IP>
You should see a message that the key was saved to a file.
5. Create a response policy with a valid management server address (same as
<Firewall_IP> from above,) set communication to Authenticated, and set the rest of the
options as appropriate to your environment. Apply this policy to the sensor.
6. Create a policy with OPSEC enabled for appropriate events. Apply this policy to
the sensor.
7. Stop and start the sensor from the WGM or Site Protector.
I have seen cases were the key exchange has resulted in key corruption. If you have
completed one of the above procedures (including the final start/stop of the sensor)
and you are seeing a high volume of empty fw_sam requests in the firewall log, there
is a good chance that the key exchange didn't work correctly. If you find yourself in
this situation, repeat the procedure from step 3 on.
Common mistakes-
1. Using key exchanges for one form of OPSEC (like plain text) when the firewall has
OPSEC set to use another (like ssl)
2. Using the wrong response (authenticated instead of authenticated and encrypted for
example)
3. Forgetting to stop and restart the firewall after altering fwopsec.conf
4. Running the opsec_putkey utility before doing a fw putkey on the firewall.
5. Running opsec_putkey from a directory other then the sensor's directory. This will
create the authkeys file in whatever directory the utility was run from. If you are
in the C: directory and run the utility from an absolute path, the file will be
created in the C: directory. rsopsecd checks only checks it's own directory for the
file.
=====================================================
John Pierce
QA Engineer - RealSecure
Internet Security Systems - The Power to Protect
=====================================================
_______________________________________________
ISSforum mailing list
[EMAIL PROTECTED]
