Hi John:
Did you test this on Cluster configuration?
StoneBeat Full Cluster, or Nokia Cluster (running VRRP)
Because it didn't work..
Regards.
Oscar E. Aviles Sandoval
Jefe de Proyecto e-Security
Cosapi Soft S.A.
We Secure communications on Internet
C Av. Javier Prado Este 4491 Surco
( (511) 3133200, Anexo 233. Cel: (511) 81.22606
+ [EMAIL PROTECTED]
-----Original Message-----
From: Pierce, John (ISSAtlanta) [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 3:37 PM
To: [EMAIL PROTECTED]
Subject: [ISSForum] Using the OPSEC response with RealSecure
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]
_______________________________________________
ISSforum mailing list
[EMAIL PROTECTED]
