If you can't fix the timestamp being used you'll probably have to modify the source code to handle it. Assigning everything to a new decoder won't help when the rules often require other decoders.
On Tue, Dec 10, 2024 at 3:37 PM BJ Taylor <[email protected]> wrote: > > So, here's my progress on this so far: > > We created a custom decoder that looks like the following: > <decoder name="RSYSLOG_SyslogProtocol23Format"> > <prematch>\S+\s\S+\s\S+\scrontab</prematch> (this part wasn't going to > stay like this, but it's working for our testing) > <regex>\S+\s(\S+)\s(\S+)\s(\S+)\s(\S+)\s\S+\s\S+\s+(\S\.+)</regex> > <order>timestamp, hostname, program_name, pid, log</order> > </decoder> > > And when we test it against a log line, we get the following: > > # /var/ossec/bin/ossec-logtest > 2024/12/10 12:58:29 ossec-testrule: INFO: Reading local decoder file. > 2024/12/10 12:58:29 ossec-testrule: INFO: Started (pid: 1944677). > ossec-testrule: Type one log per line. > > <78>1 2024-12-05T11:34:16.945687-07:00 someserver crontab 84972 - - (root) > REPLACE (root) > > > **Phase 1: Completed pre-decoding. > full event: '<78>1 2024-12-05T11:34:16.945687-07:00 someserver crontab > 84972 - - (root) REPLACE (root)' > hostname: 'someserver' > program_name: '(null)' > log: '<78>1 2024-12-05T11:34:16.945687-07:00 someserver crontab 84972 > - - (root) REPLACE (root)' > > **Phase 2: Completed decoding. > decoder: 'RSYSLOG_SyslogProtocol23Format' > timestamp: '2024-12-05T11:34:16.945687-07:00' > hostname: 'someserver' > program_name: 'crontab' > pid: '84972' > log: '(root) REPLACE (root)' > > But no rules fire. When I compare that with a more traditional log line I get > the following: > > # /var/ossec/bin/ossec-logtest > 2024/12/10 12:58:47 ossec-testrule: INFO: Reading local decoder file. > 2024/12/10 12:58:47 ossec-testrule: INFO: Started (pid: 1944710). > ossec-testrule: Type one log per line. > > 2024-12-10T09:37:10.195671-07:00 someserver crontab[98436]: (bj) REPLACE (bj) > > > **Phase 1: Completed pre-decoding. > full event: '2024-12-10T09:37:10.195671-07:00 someserver > crontab[98436]: (bj) REPLACE (bj)' > hostname: 'someserver' > program_name: 'crontab' > log: '(bj) REPLACE (bj)' > > **Phase 2: Completed decoding. > No decoder matched. > > **Phase 3: Completed filtering (rules). > Rule id: '2832' > Level: '5' > Description: 'Crontab entry changed.' > **Alert to be generated. > > So, although our custom decoder assigned a value to "program_name", it > doesn't seem to fix the fact that the "pre-decoding" couldn't find it. Rules > that match against the "program_name" are still not matching. My google > searches are coming up blank, and AI is hallucinating all over the place. If > there is anyone who has any ideas on this, I'd appreciate the help. At this > point, I'm guessing the only way to fix this is to alter the source code and > recompile, since I think that's where "phase 1: pre-decoding" happens. > > Thanks. > BJ > > On Thu, Dec 5, 2024 at 2:14 PM BJ Taylor <[email protected]> wrote: >> >> Hey, >> >> We installed ossec a few months ago, and recently realized we are not seeing >> many alerts on things that should be generating alerts. We are using OSSEC >> v3.7.0 on varioius versions of Ubuntu from 20.04 to 24.04. We use the >> built-in RSYSLOG_SyslogProtocol23Format for our logs. Unfortunately, OSSEC >> doesn't seem quite able to parse it correctly. >> >> For example: >> <78>1 2024-12-05T11:34:16.945687-07:00 someserver crontab 84972 - - (root) >> REPLACE (root) >> >> This creates the following output in the logtest: >> >> **Phase 1: Completed pre-decoding. >> full event: '<78>1 2024-12-05T11:34:16.945687-07:00 someserver >> crontab 84972 - - (root) REPLACE (root)' >> hostname: 'someserver' >> program_name: '(null)' >> log: '<78>1 2024-12-05T11:34:16.945687-07:00 someserver crontab 84972 >> - - (root) REPLACE (root)' >> >> **Phase 2: Completed decoding. >> No decoder matched. >> >> I presume that since it can't distinguish the program_name, that the rules >> that would catch an update to the crontab are not able to fire. In fact, I >> think that many of the syslog rules will never fire until we can figure out >> how to help it figure out the program name. >> >> Unfortunately, in all of my googling, and research, I have not been able to >> figure out how teach it to parse this correctly. Nothing I've read (and I >> may be looking in the wrong spots) tells me how to configure OSSEC to read a >> new log format it doesn't recognize and have it find the program_name. >> >> Any help you can give me would be greatly appreciated. And if for some >> reason, this is impossible, maybe some direction as to what formats are >> acceptable. >> >> Thanks, >> BJ >> >> -- >> >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "ossec-list" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/ossec-list/Q6RVCW84jEE/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To view this discussion visit >> https://groups.google.com/d/msgid/ossec-list/b8f096f2-02a5-4f65-a13d-e137ffda3e96n%40googlegroups.com. > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/ossec-list/CANmdzRMVRSKVNrs5Si%2BNDWqBeqxJcwQYLt1r-5uNAa-DkVhhJA%40mail.gmail.com. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/ossec-list/CAMyQvMpSMiWWZHT02B8QgwGW-km%3D6AK2hOwDQGDeV%2BFN3jsFRA%40mail.gmail.com.
