HPE GreenLake Administration
- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Issues during evaluation of Host IDS B.02.02
Operating System - HP-UX
1832611
Members
3233
Online
110043
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-17-2004 10:30 AM
02-17-2004 10:30 AM
Issues during evaluation of Host IDS B.02.02
I'm performing an evaluation of the J5083AA,r=B.02.02.16 (HIDS B.02.02) for H-pux 11.11. In the prior release we had problems because the for 11.11. In the prior release we had problems because the modifications to the filter rules were not showing up in terms of filtering out alerts. It looks like that has been resolved. However some new issues came up during my evaluation, mostly nits but a few slightly more serious.
Hopefully this is of use to somebody...
1. NIT: Even if the operator deletes all of the alerts, the desktop icon retains its alert color (Yellow, Blue, &c.) So the color can not be relied upon to notify the operator when new alerts appear.
2. NIT: Unless the "Automatic Startup Alert Synchronization" option is deactivated, restarting the idsgui causes all past alerts to reappear, even though they had been deleted.
3. NIT: Help panel needs a close button, and the icons should display hot tips so you know what they do.
4. NIT: When the Network Node dialog is brought up with alerts present, the iconic buttons do not display properly. The buttons appear narrow along the horizontal direction, making them unreadable until I resize the window and force a re-proportioning.
5. Some of the default settings for files/directories to watch for modification seem a little questionable:
* It does not include /usr/sbin among the directories to watch for modification, so it completely missed my revision of /usr/sbin/som2elf when I loaded PHCO_29436.
* It is set up to watch both /bin and /usr/bin, which I believe are be the same drectory.
* It is set up to watch /lib instead of /usr/lib
6. On an NIS'd box, the HIDS install placed the 'ids' account after the '+:' line. As a result SD did not think the 'ids' account existed, so the owner of /opt/ids and /var/opt/ids was left as root instead of 'ids'. As a result 'ids' was not able to execute the /opt/hids/bin/* commands.
7. Receiving many errors of the following form:
Code: 10002
Message: KernelIDSP:idskerndsp: Dropping
audit records due to heavy load. First
notice.
Followed a little later by:
Code: 10002
Message: KernelIDSP:idskerndsp: No longer
dropping audit records.
But I'm just running on a little workstation that is both client and admin host. I.e. no networking and not too much going on.
8. Certain HP applications are generating severity 1 filename mapping change alerts:
Type: Filename mapping change Date: Mon Feb 16 08:49:25 2004 Severity: 1
Code: 006 Version: 01 Target Subsystem: 02:FILESYSTEM
Attacker: User ID:0 Attacked: ----- (---.---.---.---)
Details: UID:0 (EUID:0) Reference:/var/stm/logs/os/memlog currently
kern_open:/var/stm/logs/os/memlog(1,33492,"40000009") was kern_unlink:/var/stm/logs/os/memlog(1,33353,"40000009")
program running is "UNKNOWN" with arguments "UNKNOWN" probably attacker was UID:0 running "UNKNOWN" with arguments "UNKNOWN".
Similar message from: /var/opt/scr/tmp/scrdaemon.pid
--
Thanks.
Hopefully this is of use to somebody...
1. NIT: Even if the operator deletes all of the alerts, the desktop icon retains its alert color (Yellow, Blue, &c.) So the color can not be relied upon to notify the operator when new alerts appear.
2. NIT: Unless the "Automatic Startup Alert Synchronization" option is deactivated, restarting the idsgui causes all past alerts to reappear, even though they had been deleted.
3. NIT: Help panel needs a close button, and the icons should display hot tips so you know what they do.
4. NIT: When the Network Node dialog is brought up with alerts present, the iconic buttons do not display properly. The buttons appear narrow along the horizontal direction, making them unreadable until I resize the window and force a re-proportioning.
5. Some of the default settings for files/directories to watch for modification seem a little questionable:
* It does not include /usr/sbin among the directories to watch for modification, so it completely missed my revision of /usr/sbin/som2elf when I loaded PHCO_29436.
* It is set up to watch both /bin and /usr/bin, which I believe are be the same drectory.
* It is set up to watch /lib instead of /usr/lib
6. On an NIS'd box, the HIDS install placed the 'ids' account after the '+:' line. As a result SD did not think the 'ids' account existed, so the owner of /opt/ids and /var/opt/ids was left as root instead of 'ids'. As a result 'ids' was not able to execute the /opt/hids/bin/* commands.
7. Receiving many errors of the following form:
Code: 10002
Message: KernelIDSP:idskerndsp: Dropping
audit records due to heavy load. First
notice.
Followed a little later by:
Code: 10002
Message: KernelIDSP:idskerndsp: No longer
dropping audit records.
But I'm just running on a little workstation that is both client and admin host. I.e. no networking and not too much going on.
8. Certain HP applications are generating severity 1 filename mapping change alerts:
Type: Filename mapping change Date: Mon Feb 16 08:49:25 2004 Severity: 1
Code: 006 Version: 01 Target Subsystem: 02:FILESYSTEM
Attacker: User ID:0 Attacked: ----- (---.---.---.---)
Details: UID:0 (EUID:0) Reference:/var/stm/logs/os/memlog currently
kern_open:/var/stm/logs/os/memlog(1,33492,"40000009") was kern_unlink:/var/stm/logs/os/memlog(1,33353,"40000009")
program running is "UNKNOWN" with arguments "UNKNOWN" probably attacker was UID:0 running "UNKNOWN" with arguments "UNKNOWN".
Similar message from: /var/opt/scr/tmp/scrdaemon.pid
--
Thanks.
1 REPLY 1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-19-2004 08:34 AM
02-19-2004 08:34 AM
Re: Issues during evaluation of Host IDS B.02.02
A work-around for #6 seems to be to fix the /etc/passwd file so that the 'ids' account is above the '+:' entry, then force re-install IDS using the appropriate swinstall options.
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Events and news
Customer resources
© Copyright 2025 Hewlett Packard Enterprise Development LP