Error when I active nr.managed daemon on the IDS sensor

r.dalessandro · ‎11-13-2001

When I try to launch the mananged daemon on the IDS sensor with 2.5(1)S2 with nrexec or nrset I have this error:

Error timeout waiting for response.

Why?What means?

marcabal · ‎11-13-2001

How are you trying to launch managed with nrexec or nrset?

Managed is started by using the management tool to include managed in the etc/daemons file.

Postoffice will then start it automatically like all of the other daemons.

To start managed using nrConfigure go the system files configuration area and open the daemons configuration. Here you can select managed to be included in the daemons file.

In CSPM the managed daemon is added to the daemons file automatically when you configure a router for blocking.

To see if managed is running, type nrstatus on the sensor.

If managed is not running then see if it is in the etc/daemons file.

If not, then follow the instructions above. It if it is in the daemons file, but is not running then try typing nrstop and nrstart to get it started.

If it won't stay running then chekc the errors file for managed.

If managed is running but not responding to nrexec and nrget queries then either managed is overloaded with too many automatic shun requests so it doesn't have time to respond, or your query is incorrect, or you've found a bug and need to contact the TAC.

Or you might try upgrading to 3.0 before contacting the TAC, there were several managed bug fixes in the 3.0 code base.

r.dalessandro · ‎11-14-2001

Thanks.

The daemon now has started;when I try to block a Ip address,i have the success banner..but on the pix i don,t see the shunning rule?!!!why?

marcabal · ‎11-14-2001

Are you executing the "show shun" command on the Pix?

Refer to: http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_61/cmd_ref/s.htm#xtocid187317

This is a new command which is only available with Pix 6.0 or higher.

Managed uses this command, so you must be running Pix 6.0 or higher to manage the Pix.

NOTE: The "Success" that you receive is acknowledgement that managed has received and accepted your request. It is not meant to say that the change of the router or pix configuration was a success. The actuall changing of the router or pix configuration could take a little while depending on how many shuns are being done and how many different devices are being managed. So if managed waited to respond to your shun request until after all the devices had been updated, then it is possible that you command would timeout.

So to verify if managed is functioning properly, you should check the managed error files. If managed comes across an error in configuration then it will place that error in it's error file.

If there is no error file, and you still don't see any shuns on the Pix, then you can try the following:

NOTE: You will need to open one telnet window to the sensor as user netrangr, and a second telnet window as user root.

As netrangr: nrstop

As root: snoop -d iprb0 -o /tmp/packets.snoop

(If using IDS-4210 change iprb0 to iprb1)

As netrangr: nrstart

Now execute a shun request

Wait a minute

As root: Use Ctrl-C to stop the snoop command

As root: Use different snoop options to analyze the packets that are being sent to the Pix and the responses from the Pix. This will let you know of any errors being generated.

Example snoop commands to try:

snoop -i /tmp/packets.snoop | more

snoop -i /tmp/packets.snoop -v | more

snoop -i /tmp/packets.snoop -x 0 | more

r.dalessandro · ‎11-15-2001

I also have configured a router like blocking devices and with it the shunning is functioning proprerly..

I try to see with the snoop command what happen really with the pix.

Thanks care.

stleary · ‎11-15-2001

You can check the current status of devices controlled by nr.managed by typing this at

the Sensor command line:

nrget 10003 hostid orgid 1 Diagnostic

(replace with your sensor hostid and orgid)

All devices should be in the 'Active' state. If not, then something is wrong,

probably in the sensor configuration.

Nr.managed can only telnet to a PIX on the inside interface. If you are using

the outside (or DMZ) interface, then nr.managed has to be configured

to use SSH. In that case, the PIX should have a 3DES key installed, and be

configured to allow SSH sessions to the PIX.

r.dalessandro · ‎11-15-2001

The pix's status is inactive. I have opened the errors.managed file and there are the following messages:

11/14/2001 17:43:24UTC E Net Device offline at address [192.168.109.1] State [Connecting] SubState [Initial], resetting now.

11/14/2001 17:44:04UTC E Connection lost to net device 192.168.109.1

11/14/2001 17:44:04UTC E Can not set send bufsize on socket

11/14/2001 17:44:04UTC E Can not set recv bufsize on socket

11/14/2001 17:44:04UTC E Read error [Invalid argument] fd [1]

11/14/2001 17:44:50UTC E Connection lost to net device 192.168.109.1

The IDS communicate with the pix on the inside.

thanks.