is it possible to send alarms from one IDS probe to 2 differents CSPM servers ? (if one
is down,other can be as backup ) ?
i didnt see in documentation how to do that ?
thanks in advance
Definately can be done in several ways in either the sensor or from one CSPM (director) to another. Depends if you are better with editing Unix files of the GUI.
Searching on destinations will give you the method with the device manager. If you prefer to edit the Unix files, just post and I can add the info.
The group I work with is also interested in using a primary/backup CSPM server architecture. We have 2 CSPM servers on the network but have been unable to get both of them to talk to our 9 sensors at the same time. I also had to manualy enter the topolgy in both CSPM servers because the backup server did not like the copy from the primary. When I tried to save the topology file in the backup server I got an error that there was a duplicate device and the file could not be saved.
In any case, I would like more information on your solution. The URL that you have given talks about the sensor Device Manager but I do not see a reference on how to add a second CSPM server using the CSPM GUI.
As for the Unix file edits, this could be an alternative solution for us as long as it is a stable solution. I assume you are talking about editing one or more of the configuration files in the /usr/nr/etc directory of the sensors. Could you also give some more information on this.
Thank you for your help.
CSPM does not currently support a primary/backup type model.
What it does support is having one CSPM for configuration and alarm viewing, and using a second CSPM as a secondary destination only for alarm viewing.
For this example I will use 2 CSPM machines: CSPMA and CSPMB.
CSPMA is configured like a normal CSPM for configuring and receiving alarms from the sensors. CSPMA would be where all of your configuration takes place on a normal daily basis.
Within CSPMA you would configure each sensor to also send it's alarms to a secondary destination CSPMB. This is in the Advanced->Additional Destinations Tab.
On CSPMB you would add a machine for each sensor. But instead of adding them as sensors, you would just add them as postoffice hosts. This way the sensors will be communicating with and sending alarms to CSPMB, but CSPMB won't be able to configure them.
Refer to the following link about adding Postoffice hosts.
Alternatively you could also add the sensors in as real sensors, but when adding the sensor do not select the check boxes that verify the sensor information. CSPMB won't have the permissions necessary to verify the sensor informaiton. If you do this you will have to remember that CSPMB should NEVER be used for configuration changes in this state.
The end result is that the sensor is configured ONLY by CSPMA, but is sending alarms to both CSPMA and CSPMB. As long as CSPMA continues operating, the alarms in CSPMB should be deleted on a daily basis to keep it's alarm database from filling up with old alarms.
So what happens if CSPMA goes down:
Option1) If you have IDS Appliances, and are running 3.1(2)S23 or later, then you can manage the IDS Sensors using the IDM web based client until CSPMA comes back on line. Then the changes made through IDM will have to be manually redone within CSPMA. Personally I would suggest using this option, even though it makes you keep track of what changes you make through IDM so you can incorporate them back into CSPMA.
NOTE: During this time CSPMB would be used for alarm viewing.
Option2) If you want to use CSPMB for configuration, then delete the current Postoffice Host for the sensor within CSPMB. Go to the sensor and manually edit the etc/auths file to add all authority for CSPMB, and restart the sensor. Now add the sensor to CSPMB and select both check boxes. CSPMB will now have permission to pull the latest information from the sensor. If you dont' remove the sensor and re-add it, then CSPMB won't know all of the configuration changes that had previously been made by CSPMA. You would have to do this for each sensor. When CSPMA comes back on line, you will have to reconfigure each sensor to give CSPMA authority. And then delete and re-add them to CSPMA to get all of the changes that CSPMB had made.
This option can be very time consuming if you have multiple sensors.
I need to open this thread again..............
Are the instructions saying that you have to define the sensor as a host and then configure the CSPM server node to receive alarms from it or forward alarms to it?
How can something that seems so easy, be such a pain in the a**?
CSPMA configures the sensor to send alarms to CSPMB by adding CSPMB as an additional destination when configuring the sensor.
Then CSMB adds the sensor to it's topology as a postoffice host fom which it should receive alarms.
Have you got this to work?
I've had success with getting alarms to go to 2 different CSPM boxes with the second method you've mentioned. I'd like to try to get this postoffice host option to work as well.
I've never tried it myself.
I am passing along information that I've received from our CSPM development team.
The feature was tested by their test team and should work.
If you can't get it to work you may want to try calling the TAC.
Be prepared to provide the following to the TAC:
The CSPM database file for both CSPMA and CSPMB.
And the etc configuration files from the sensor.
Things that may help in your troubleshooting:
Look in the etc/hosts and etc/routes files in CSPMB for the sensor information.
The etc/hosts and etc/routes files are in the postoffice subdirectory of the CSPM installation directory.
If the sensor information is not winding up in your etc/hosts and etc/routes files on CSPMB, then it is either a configuraiton issue, or a bug in CSPM.
I heard awhile back that the postoffice config files aren't updated if there are no sensors in the configuration. If CSPMB has nothing but postoffice hosts (and not sensor nodes) then try adding a single dummy sensor to the configuration. (A dummy sensor being a sensor entry using made up ips and address that don't correspond to a real sensor). Then Update CSPM and check the configuration files again.
If adding the dummy sensor doesn't get the conf files updated then i would have to guess it is something in your configuration or another CSPM bug I may not be aware of.
If the configuration files for CSPMB are being updated, but you are not seeing alarms then let me know, and there are other things to do to diagnose those types of communication issues.
Thanks for the help on this issue. I was able to get our IDS sensors to send alarms to both of our CSPM servers. But I have a question.
On CSPMB I added the IDS devices as sensors and on the "Control" tab I designated CSPMB as the "Policy Distribution Point".
On CSPMA, for each sensor, I designated CSPMB as the "Additional Destination" using the "smid" service.
An "nrconns" on any of the sensors shows "Established" with both CSPMA and CSPMB. I also see alarms in the Event Viewer window of both CSPM servers.
The IDS topology in the two CSPM servers are the same except for the CSPM server that is used within the topology. (I hope that makes sence)
My question is why can't I go ahead and add a line in the \etc\auths file of each sensor that says "CSPMB.orgid GET,GETBULK,SET,UNSET,EXEC".
Would there be any problems with this. My thought is that if this entry is already in the \etc\auths file and CSPMA goes down then I could go to CSPMB and update each sensor with the "Approve Now" botton on the "Command" tab.
This would be a relatively quick way to get the backup CSPM server on-line. For regular use only CSPMA would be used for configuration changes and sensor updates. CSPMB would just be used to monitor alarms. What do you think? Thanks again for the help.
In theory editing the sensor's auths files to include CSPMB authorizations sounds good, until you realize that the auths file gets overwritten each time CSPMA pushes a new configuration. So once you make a change to the sensor in CSPMA then the edits you made to the auths file are gone.
A possibility I hadn't considered is that instead of making the edit on the sensor, you could add that line to the default template file for the auths file. Each configuration file as one more template files for it.
Find the templates directory on your CSPM installation directory. Under it you will see different version directories. Find which directories contain auths file templates. Edit each of these auths file templates to contain the CSPMB line, and then Update and Approve new configs to each sensor. Each sensor then should have the correct auths file line.
I haven't tried this before, so you would be the first. Let me know if you decide to try this, and how it goes.
NOTE: In CSPMB you would need to do the same for CSPMA,
Marcoa, I followed your directions and found an auths.template file in the \templates\common\etc and the \templates\LocalPostoffice directories on CSPMA. I added the CSPMB line to these 2 files, did an Update and then did an Approve Now for one of the sensors. (These are production machines so I have to be a little careful). I telneted into the sensor and did a cat of the auths file in the \usr\nr\etc directory. Sure enough the CSPMB line had been added to the sensor file. An nrconns showed the sensor was still talking to both CSPM servers so I went ahead and did an Approve Now for the rest of the sensors. They all worked fine.
The only drawback I see to this primary/backup solution is that in the event of CSPMA going down I still have to telnet into each sensor to manually change the IDS manager's host name, ID and IP address. I will write a script to speed this process up but getting CSPMB to take over for CSPMA is still going to produce a few minutes of outage time.
Given the current CIDS design and software support I guess this is the best solution for now.
Thanks again for all of your help.