In addition,: If you messed up the key part, and it was not successful on the first try (which happens a lot), try to use a different key on each the following tries. Make sure that you see the message on the real secure network sensor that tells you that the key is saved to a file. If you don't see this message, do not try further steps, go back and do the putkeys again.
-----Original Message----- From: Pierce, John (ISSAtlanta) [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 1: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]
