UPDATE! The community will be go into read-only on April 19, 8am Pacific in preparation for migration on April 21. Read more.
UPDATE! The community will be go into read-only on April 19, 8am Pacific in preparation for migration on April 21.Read more.
Absent Member.
Absent Member.
3627 views

Preview of SUSE Linux Enterprise Server is released

Hello!

MicroFocus release a new Preview-Version of the "SUSE Linux Enterprise Server Collector 2011.1r3:

Download: https://www.netiq.com/support/sentinel/plugins/pre/collectors/Novell_Open-Enterprise-Server_2011.1r1-201403120737-preview.clz.zip
Documentation: https://www.netiq.com/support/sentinel/plugins/pre/collectors/Novell_Open-Enterprise-Server_2011.1r1-201403120737-preview.pdf

Release Notes 2011.1r3:


  • To avoid any misinterpretation of the event, if there is no Source and Target host information from the event source, the Collector no longer copies the Observer host information to the Source and Target host fields.
  • Fixed sshd PAM event to parse the SourceHostName/SourceIP properly in Sentinel. (Bug# 973420)
  • Fixed ssh login event parsing issues for laf events. (Bug# 972170)
  • Fixed parsing issues for postfix events. (Bug# 970487)
  • Fixed parsing issues for failed login-user not known event. (Bug# 948218)
  • Fixed parsing issues for sshd connection terminated before authentication event. (Bug# 943003)
  • Kernel messages will be loaded as unsupported events without being dropped. (Bug# 954768)
  • Fixed IP parsing issue for ssh termination event. (Bug# 889064)


A significant change is the decision that the Collector no longer copies the Observer host information to the Source and Target host fields. That means, every SSHD or WTMP-Event is incomplete. Of course it is right that the information about the Traget host is not provided by the forwarded event.

On the other hand MicroFocus copies the TargetUsername (dun) to the InitiatorUsername (sun) field.

Example: Connecting with putty from a Windows Workstation with the logged on User "Jane Doe" to a Linux Server with username "root" results in the paresed event that user "root" comes from a Windows Workstation and connecets withe username "root" to the Linux Server ... that's realy wrong.

In my humble opinion it's better to copies the Observer host information to the Source and Target host field as copying the TargetUserName to the InitiatorUserName field.

Or, another possibility, copies the Observer host information to the Source and Target host field and tag this fact so a security analyst can realize this.

What do you think?

Sincerely Jan
0 Likes
22 Replies
Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class

rmjan79;2427827 wrote:

I'm not sure if the third point is correct: "Source host should always be populated for all events; where a source is not specified, the target should be assumed to be the observer."

If I'm not wrong it must be: "Source host should always be populated for all events; where a source is not specified, the source should be assumed to be the observer." Right?



Correct! That was a copy/paste bug. At least I wasn't copying off Stack Overflow. 🙂
0 Likes
Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class

tfechner;2427744 wrote:
" If the context of the event suggests that an unspecified source is not local to the observer, source host should be left blank."
sorry - I totally disagree here.
ALL events should have a source.All packets received do have a IP source. So why not use this?
For me the most valuable information on an event is: where does this event come from? what source host reported this event?
There is a discussion whether to use the reporter or the source host as the fundamental source of the message.


The scenario here is (I hope) a rare one - you have an event that indicates that something happened, and the context event tells you that the source DEFINITELY originated remotely, but for whatever reason the event does not provide that information. That information is definitely not the observer.

This actually happens more than I like with InitiatorUser. My favorite is some old VMware 5 events where the syslog event says nothing more useful than "A user was created". "

What I want to ensure is that the rule doesn't have people blindly copying Observer to satisfy the criteria, but actually looking at the information and confirming that the source/target is really local to the observer - otherwise you guys open SRs to tell us that the event is nonsense. That's happened, and that's why this original change was made - we had quite a few issues where blind copying resulted in bad information scenarios.
0 Likes
Absent Member.
Absent Member.

On 03.05.2016 12:36, tfechner wrote:
>
> " If the context of the event suggests that an unspecified source is not
> local to the observer, source host should be left blank."
> sorry - I totally disagree here.
> ALL events should have a source.All packets received do have a IP
> source. So why not use this?


Events describe actions. But not all actions involve IP traffic, e.g. a
"useradd" on a Unix box. Even if an event is about IP traffic, there
might not be a value to go into source IP, e.g. "DDOS attack on
192.0.2.123 (ntp.example.com) detected".

Syslog messages received by a Sentinel event source server do have a
Source IP. That information goes into ReporterIP. It may be the IP of
the device where the message originated or that of a relay. Only with
knowledge about the network's topology one could tell if the Observer
was also the Reporter.

> For me the most valuable information on an event is: where does this
> event come from? what source host reported this event?
> There is a discussion whether to use the reporter or the source host as
> the fundamental source of the message.
>
>



--
Norbert
0 Likes
Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class

brandon.langley;2427725 wrote:
I had a long conversation with Norbert today and we adjusted our thought processes a bit more in line with the idea that since most of our taxonomies have cases where there can be a source or a target, in general populating these fields based on the context of the event seems like the more rational thing to do. Also, we caught a corner case we want to address for future goodness. Here is the updated thought process (draft, expect us to clean up our wording later)

* Target host should always be populated for all events; where the target is not specified, the target should be assumed to be the observer.
* If the context of the event suggests that an unspecified target is not local to the observer, target host should be left blank.
* Source host should always be populated for all events; where a source is not specified, the target should be assumed to be the observer.
* If the context of the event suggests that an unspecified source is not local to the observer, source host should be left blank.
* If the hostname is 'localhost' or the IP is a loopback (127.0.0.1/::1), the hostname/ip should be updated to the appropriate observer value.

Please add feedback - We plan to come to a conclusion on this week so that we can address the open issues and release this when we certify SUSE 12 support (although it's possible a preview build will be made available sooner)



With no additional feedback and no dire screams of 'nay', I am going ahead and putting this into production. Minus the copy/paste error. Thank you to everyone who's taken the time to comment here.
0 Likes
Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class

brandon.langley;2428233 wrote:
With no additional feedback and no dire screams of 'nay', I am going ahead and putting this into production. Minus the copy/paste error. Thank you to everyone who's taken the time to comment here.


For additional clarity, these are the rules that I am documenting and asking to have put into production on all subsequent collector updates, based on the feedback in this thread:

* Target host (name and/or IP) should always be populated for all events; where the target is not specified, the target should defined as the same host as the observer.
* If the context of the event suggests that an unspecified target is not the same host as the observer, target host should be left blank.
* Source host (name and/or IP) should always be populated for all events; where a source is not specified, the source should defined as the same host as the observer.
* If the context of the event suggests that an unspecified source is not local to the observer, source host should be left blank.
* If the host name is 'localhost' or the IP is a loop back address (127.0.0.1/::1), the host name/IP should be updated to the appropriate observer value.
* Observer should only be populated when it's clear and understood where the data originated from. When not clear, only the Reporter host information should be populated.

Please continue to post in this thread if you have additional questions or need clarification.
0 Likes
Absent Member.
Absent Member.

Sorry, was not in the office the past 5 days. For the moment the new "draft" sounds good to me and i can't find any logical mistake ... but we all know the devil is in the details. We test the new collector version and then we will see 🙂
0 Likes
Absent Member.
Absent Member.

Hello Mr. Langley,

i was surprised while reading the Release Notes of the IBM AIX Collector 2011.1r2:

To avoid any misinterpretation of the event, if there is no Source and Target host information from the event source, the Collector no longer copies the Observer host information to the Source and Target host fields.

It looks like Micro Focus define its own standards (draft) for each product collector :(. That does not make sense. Is there no development draft for collector plugins??

Sincerely Jan
0 Likes
Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class

rmjan79;2435726 wrote:
Hello Mr. Langley,

i was surprised while reading the Release Notes of the IBM AIX Collector 2011.1r2:

To avoid any misinterpretation of the event, if there is no Source and Target host information from the event source, the Collector no longer copies the Observer host information to the Source and Target host fields.

It looks like Micro Focus define its own standards (draft) for each product collector :(. That does not make sense. Is there no development draft for collector plugins??

Sincerely Jan


Hopefully that was just an accidental doc update miss from the original set of changes that didn't get updated when we changed the parsing back to follow the rules above. If you see that functionality is is not behaving as we've previously talked about in this thread, please open an SR and we'll get it addressed. In the meantime I'll forward this to the appropriate lead and ask them to look into it.

Thanks,
Brandon
0 Likes
Absent Member.
Absent Member.

brandon.langley;2435885 wrote:
Hopefully that was just an accidental doc update miss from the original set of changes that didn't get updated when we changed the parsing back to follow the rules above. If you see that functionality is is not behaving as we've previously talked about in this thread, please open an SR and we'll get it addressed. In the meantime I'll forward this to the appropriate lead and ask them to look into it.

Thanks,
Brandon


Hello Brandon,

unfortunately it's not only a documentation issue, the collector works as in the release-notes described. The Source and Target fields are empty after update to the IBM AIX Collector 2011.1r2.

Of course the collector comes from April 2016, but there is no beta- or preview-version or something else.

As suggested i've reported the issue to my PSE, he opend a SR for us.

Regards Jan
0 Likes
Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class

rmjan79;2435906 wrote:
Hello Brandon,

unfortunately it's not only a documentation issue, the collector works as in the release-notes described. The Source and Target fields are empty after update to the IBM AIX Collector 2011.1r2.

Of course the collector comes from April 2016, but there is no beta- or preview-version or something else.

As suggested i've reported the issue to my PSE, he opend a SR for us.

Regards Jan


The good news is, there's a release that should already have been published (r3) that had these changes, but for some reason it's not published to the website. I will reach out and see what I can find out. I was able to confirm with the team that this issue was addressed in r3.
0 Likes
Micro Focus Frequent Contributor
Micro Focus Frequent Contributor

There is batch of 13 Collectors scheduled to go out today and this Collector is part of it. It will released in couple of hours.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.