IDS & resmon

[BSSG]

On a 11.11 test system I have loaded IDS 2.1, configured as both client and admin host. After creating my own schedule I began to receive a significant number of alerts generated by resmon. (Due to updates of resmon logs; use of lock files; pipes, &c.)

In the 'File Modification / Templates / Modification of Files/Directories' category, I added '/etc/opt/resmon' to the list of directories to ignore. Unfortunately the same alerts are still being generated in spite of this filter. I ruled out any other template causing this problem by unselecting everything except the above.

So it almost appears that this may be a bug. Does somebody have a fix for this, other than by crippling resmon?

Thank you.

--
Bob

[Ron Freund]

Hi:
Event Monitoring Service has several noisey
dirs underneath /etc/opt/. You might try filtering the log dir. contents specifically, since those get updated alot.

api.log
armmon.log
client.log
emsagent.log
registrar.log

Reference Appendix F, pg 218
page 84 (top).

Ron

[Norman Nie]

Hi Bob,

You need to put a slash at the end of the resmon, ie. `/etc/opt/resmon/` to the list of directories to ignore.

Hope this helps.

Norman

[Norman Nie]

Hi Bob,

Please disregard my previous reply. I believe the problem is caused by the fact that the original templates are read-only, therefore your modification has no effect.

The proper way to do this is:

1. Go to the Schedule Manager, under the Surveilllance Groups column, select the FileModification template, then click the Copy button below it, which creates a duplicate template. Give it a new name, such as "myFileMod", then changed the "Ignore these directories" property to include the `/etc/opt/resmon` as you did before.

2. Also in the Schedule Manager, under the Schedules column, either select one of the schedules you are using, then click on the Copy button, or use the New button to create a new schedule. Give it a new name. Click on the new schedule. You then need to deselect the default Surveillance Groups, and select the "myFileMod" Surveillance Group.

3. In the System Manager window, activate your new schedule.

Cheers,

Norman

[BSSG]

Thank you. Unfortunately none of these suggestions appeared to have worked.

I created a copy of the LoginMonitor surveillance group; deselected everything except Modification of Files/Directories in that group, then added /etc/opt/resmon/ to the list of directories to be ignored. Unfortunately it is still generating "Filesystem change detected" notices from /etc/opt/resmon/...

I'd rather not simply add the suggested log files to the ignore list for two reasons: it is also generating pipe files that have random names which can't be filtered; doing so doesn't actually address the problem I'm having with the ignore directories filter.

Now I'm getting a "No agent available" status for some reason. So I'll need to diagnose that one also. Ah well...

[Norman Nie]

Hi Bob,

You wrote:

"I created a copy of the LoginMonitor surveillance group; deselected everything except Modification of Files/Directories in that group, then added /etc/opt/resmon/ to the list of directories to be ignored. Unfortunately it is still generating "Filesystem change detected" notices from /etc/opt/resmon/... "

Did you also create a new Schedule, say "mySched", and add your LoginMonitor surverillance group to it, and then activate the new schedule?

You wrote:

"I'd rather not simply add the suggested log files to the ignore list for two reasons: it is also generating pipe files that have random names which can't be filtered; doing so doesn't actually address the problem I'm having with the ignore directories filter."

The pipe files can be filtered out if you ignore the "/etc/opt/resmon/pipe/" directory. But ignoring "/etc/opt/resmon" already covers that.

If you post some sample alerts here, I'd be happy to take a look.

Norman

[BSSG]

Sure, here's a typical alert:

Type: Filesystem change detected Date: Tue Aug 26 10:50:19 2003 Severity: 2
Code: 027 Version: 01 Target Subsystem: 02:FILESYSTEM
Attacker: Use ID: 0 Attacked:
Details: User 0 opened for modification/truncation "/etc/opt/resmon/lock/persistence.lck" executing "UNKNOWN" with arguments "UNKNOWN" as PID: "UNKNOWN"
----

Other examples of files reported:

/etc/opt/resmon/pipe/3292848383
/etc/opt/resmon/log/registrar.log

The pipe ID is a seemingly random number that changes with each alert.

---

IDS has generated 1209 alerts in about 4 hours. I've tried re-installing and reconfiguring the IDS package with no success. Thanks.

[Norman Nie]

Hi Bob,

Your alerts looked normal to me, so I'm a bit puzzled.

Could you post the text version of your schedule? To do that, click the schedule you are using in the Schedule Manager, then click on the "Details" Tab, then hit the Save button. It will say something like "Surveillance Schedule saved as: /opt/ids/bin/gui/logs/xxxx.txt"

Norman

[BSSG]

Okay, here it is:

SCHEDULE BobMonitoring
GROUPPERIOD
NAME BobsFileMods
PRIORITY 0
SPECIFIEDTIME no
GMT 0
STARTTIME 0:00:0
ENDTIME 23:59:6
GROUP BobsFileMods
TEMPLATE megaReadOnly
ADD DATA ("read_only_files_to_watch", ["/stand/vmunix", "/stand/kernrel", "/stan
d/bootconf", "/etc/passwd", "/etc/group", "/.rhosts", "/.shosts", "/etc/inetd.co
nf"])
ADD DATA ("read_only_files_to_not_watch", ["/etc/ptmp", "/etc/.pwd.lock", "/etc/
utmp", "/etc/utmpx"])
ADD DATA ("read_only_dirs_to_watch", ["/etc", "/bin", "/sbin", "/stand", "/lib",
"/usr/bin", "/opt"])
ADD DATA ("read_only_dirs_to_not_watch", ["/etc/opt/resmon/"])
ENDTEMPLATE
ENDGROUP
ENDGROUPPERIOD
ENDSCHEDULE

--
Bob

[Norman Nie]

Hi Bob,

Hmm...this is weird. I compared your schedule with mine, and it looked fine. I even created a test schedule just like yours, and activited it, and IDS runs fine without the resmon alerts. Only when I removed the "ignore /etc/opt/resmon/" entry, alerts were generated.

Norman

[Norman Nie]

Hi Bob,

You might want to check your /var/opt/ids/schedule on the agent system that's running a schedule instead of what the GUI prints. Perhaps they are different for some
reason, although I doubt that.

The other option is to wait for v2.2, which is coming out soon and has the resmon filtering by default. You can check the software product website towards the end of this month.

Cheers,

Norman

[BSSG]

>> You might want to check your /var/opt/ids/schedule on the agent system that's running a schedule instead of what the GUI prints. Perhaps they are different for
some reason, although I doubt that.<<

Yes they are different. Hmm, interesting. This looks like the relevant entry:

ADD DATA ("read_only_dirs_to_not_watch", [" "])


>> The other option is to wait for v2.2, which is coming out soon and has the resmon filtering by default. You can check the software product website towards the end of this month.<<

Well I was actually aiming to find a fix for the problem in IDS, rather than the symptom in resmon. I already have a way to reduce the amount of resmon logging.


Thanks.

[Norman Nie]

Interesting, what are the permission bits for /var/opt/ids/ and /var/opt/ids/schedule?

They should be:
drwxr-xr-x ids ids /var/opt/ids/
-rw------- ids ids /var/opt/ids/schedule

Also, look into /var/opt/ids/error.log to see if they are any error messages.

If it's a permission issue, it should have error messages such as "...failed to create schedule path filename", "...failed to open schedule path file ...", or "...failed to create/overwrite schedule path file ..."

Norman

[BSSG]

Norman,

The permissions are:

drwx------ ids ids /var/opt/ids/
-rw------- ids ids schedule

There are plenty of error messages in /var/opt/ids/error.log, but none that include the word "failed".

--
Bob

[Norman Nie]

Bob,

The permission bits looked right.

You can do the following to see if there are any error messages generated for the failure of updating the schdule file on your agent host.

1. rename /var/opt/ids/error.log on the agent host

2. rename /var/opt/ids/gui/guiError.log on the admin host

3. restart GUI and agent, activate your schedule from the GUI. The schedule is passed from the GUI to the agent. That's why the /var/opt/ids/schedule on the agent host should be the same as the one you see in the GUI.

4. check for the new /var/opt/ids/error.log and /var/opt/ids/gui/guiError.log files. Let me know if you see any error messages.

Norman

[BSSG]

Okay I renamed the two files and rebooted the system to get the daemon restarted cleanly.
(My manager and agent are on the same system.) When I bring up IDS from the ids account, it starts adding in alerts and became wigged out after it hit a thousand+. At that point the status line changed to "No Agent Available".

I am unable to activate a schedule to run. It gives the error: The following hosts are in an invalid state for this command. In order to activate a surveillance schedule, selected hosts must have a status of Ready, Scheduled, or Running.

'ps -x|grep -i ids' shows the following daemons running:
--
./idsagent -a

idskerndsp -c 6 -o /var/opt/ids//ids_1002 -s 7 -q 16384

idssysdsp -c 8 -o /var/opt/ids//ids_1002 -s 9 -q 16384 -f /var/adm/sulog SYS_SULOG -f /var/adm/syslog/syslog.log SYS_SYSLOG -f /var/adm/btmp SYS_BTMP -f /var/adm/wtmp SYS_WTMP

/opt/java1.3/jre/bin/../bin/PA_RISC2.0/native_threads/java -Dhp.swing.useFastSwing=true -Duser.dir=/opt/ids/bin/gui -Dhp.ids9000.baseDir=/opt/ids -Dhp.ids9000.etcDir=/etc/opt/ids -Dhp.ids9000.varDir=/var/opt/ids -Dhp.ids9000.commType=Version2_0 -Dhp.ids9000.bindInterface= -Dhp.ids9000.traceLevel= -Dhp.ids9000.agentPort=2985 -Dhp.ids9000.adminPort=2984 -classpath /opt/ids/bin/gui:/opt/ids/bin/gui/symlib/swingall.jar:/opt/ids/bin/gui/symlib/symclass.jar:/opt/ids/bin/gui/symlib/sfc.jar:/opt/ids/bin/gui/symlib/symbeans.jar:/opt/ids/bin/gui/symlib/collections.zip:/opt/ids/bin/gui/symlib/icebrowserbean.jar:/opt/ids/bin/gui/symlib/jsdk.jar:/opt/ids/bin/gui/symlib/symtools.jar:/opt/ids/bin/gui/symlib/Olite35.jar:/opt/ids/bin/gui/symlib/templates.jar:/opt/ids/bin/gui/javaHelp/jh.jar:/opt/ids/bin/gui/idsgui.jar:/opt/java1.3/jre/bin/lib/sunrsasign.jar:/opt/java1.3/jre/bin/lib/jsse.jar:/opt/ids/bin/gui/jsse.jar:/opt/ids/bin/gui/jcert.jar:/opt/ids/bin/gui/jnet.jar com.hp.Sentinalv0101.SentinalMain

[Norman Nie]

Hi Bob,

For the error message, "It gives the error: The following hosts are in an invalid state for this command."

You can select the host, then click on the Status button, to get the current state of the agent. Then you can activate the schedule to the agent.

By the way, you don't need to reboot the system to restart the agent.

To stop the agent, you can do "/sbin/init.d/idsagent stop". or do "ps -fu ids" to get the PIDs of ids process, and do "kill -TERM ".

To start the agent, you can cd to /opt/ids/bin, and do ./idsagent, and ./idsgui; or do "/sbin/init.d/idsagent start"

Cheers,

Norman