Re: Talking to a syslog server

Hello Evan,

thanks for clarifying. Yes, apparently I got on the wrong track by your wording. No big deal. :-)


Am 17.10.2024 um 03:27 schrieb Evan Harris <auctionitis@xxxxxxxxx>:

On the IBM i you have a myriad of possible sources, and much much larger number of events to send over. You could theoretically just send them all, but in my experience (admittedly limited) a certain amount were filtered out as they were of no value and would just waste storage and bandwidth..Even with filters on we got feedbak about "the deluge" of events generated by the IBMi.

Granted. When seen in context with the OPs (Rob Behrendt's) comment, I do not object at all. Since I don't know why he wants to do that, some further comments.

From my somewhat limited experience, nowadays there are mainly two scenarios for pushing syslog messages over the network:

- Central logging for a limited number of "dumb" devices, such as SAN appliances, network switches, routers, etc. The logs are usually just saved and regularly purged away unregarded unless there is a reason to look for clues if something was going bonkers.

- Central logging for everything which is able to provide log data. Goal is a more or less elaborated automatic calculation of "relevant" events from a global view over saved log data. See https://en.wikipedia.org/wiki/Security_information_and_event_management

For the latter, it's said to better be safe than sorry and just shove every event over, letting the SIEM software decide which events are relevant and which aren't.

FYI we have looked at various times at sending Audit data, QHST records, journal changes for selected tables/columns and message queues.

Granted, journal changes might quickly become a major generator of events. I also can see that this data could be an indicator of compromise, in a SIEM context. On the ther hand, journal changes are very IBM i specific. I don't know if there are IBM i "aware" SIEMs out there.

:wq! PoC