Parser Failure: "Line 0/2 is missing evt.StrTime"

[m0urs]

After installing CrowdSec on my Debian machine, I tried the following command

tail -n 2 /var/log/apache2/access.log | cscli explain --type apache -f -

to check if the Apache log file can be parsed correctly.

However, I do get a "Parser Failure" and I am now wondering if something is wrong with my installation?

WARN[20-01-2024 11:02:23] Line 0/2 is missing evt.StrTime. It is most likely a mistake as it will prevent your logs to be processed in time-machine/forensic mode.
WARN[20-01-2024 11:02:23] Line 1/2 is missing evt.StrTime. It is most likely a mistake as it will prevent your logs to be processed in time-machine/forensic mode.
line: 47.76.35.19 - - [20/Jan/2024:11:02:19 +0100] "GET /picture.php?%2F4311%2Fcategories%2Fposted-weekly-list-2019-19-4= HTTP/1.1" 302 580 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.2794.21 Safari/537.36" - gallery.urspringer.de:80
        ├ s00-raw
        |       ├ 🟢 crowdsecurity/non-syslog (+5 ~8)
        |       └ 🔴 crowdsecurity/syslog-logs
        ├ s01-parse
        |       ├ 🔴 crowdsecurity/apache2-logs
        |       ├ 🔴 crowdsecurity/mysql-logs
        |       ├ 🔴 crowdsecurity/nextcloud-logs
        |       └ 🔴 crowdsecurity/sshd-logs
        └-------- parser failure 🔴

line: 47.76.35.19 - - [20/Jan/2024:11:02:19 +0100] "GET /picture.php?%2F4269%2Fcategories%2Fposted-weekly-list-2019-19-4= HTTP/1.1" 200 5215 "-" "Mozilla/5.0 (Windows NT 6.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.2595.66 Safari/537.36" - gallery.urspringer.de:443
        ├ s00-raw
        |       ├ 🟢 crowdsecurity/non-syslog (+5 ~8)
        |       └ 🔴 crowdsecurity/syslog-logs
        ├ s01-parse
        |       ├ 🔴 crowdsecurity/apache2-logs
        |       ├ 🔴 crowdsecurity/mysql-logs
        |       ├ 🔴 crowdsecurity/nextcloud-logs
        |       └ 🔴 crowdsecurity/sshd-logs
        └-------- parser failure 🔴

I do get a similar error if I try the same with my SSH log file:

tail -n 1 /var/log/auth.log | cscli explain --type ssh -f -

WARN[20-01-2024 11:08:53] Line 0/1 is missing evt.StrTime. It is most likely a mistake as it will prevent your logs to be processed in time-machine/forensic mode.
line: Jan 20 11:08:09 vs1 sshd[36648]: Connection closed by 127.0.0.1 port 22706 [preauth]
        ├ s00-raw
        |       ├ 🟢 crowdsecurity/non-syslog (+5 ~8)
        |       └ 🔴 crowdsecurity/syslog-logs
        ├ s01-parse
        |       ├ 🔴 crowdsecurity/apache2-logs
        |       ├ 🔴 crowdsecurity/mysql-logs
        |       ├ 🔴 crowdsecurity/nextcloud-logs
        |       └ 🔴 crowdsecurity/sshd-logs
        └-------- parser failure 🔴

Did I miss something?

However: I see alerts and decisions generated by CrowdSec:

[LaurenceJJones]

Both failures to parse are not the same cause

So, the Apache2 logs most likely failed because you are using a custom format to append the subdomain onto the end of the line. Edit: my initial presumption is most likely wrong given I can see some bad user agents trigger so many it certain lines

The ssh logs failed because the attempt was just a preauthed and wasn't an actual attempt to log in with user/pass or keys

Once I am back on Monday, I can try to debug apache logs further, however, for ssh you can grep to file for the word failed grep -i failed /var/log/auth.log | tail -n1 | cscli ...

And that should parse correctly

[m0urs]

@LaurenceJJones Thank you!

Should this work for SSH:

echo "Jan 20 00:13:07 vs1 login[732]: FAILED LOGIN (1) on '/dev/tty1' FOR 'root', Authentication failure" | cscli explain --type ssh -f -
Because I also get the same result:

WARN[20-01-2024 12:54:22] Line 0/1 is missing evt.StrTime. It is most likely a mistake as it will prevent your logs to be processed in time-machine/forensic mode.
line: Jan 20 00:13:07 vs1 login[732]: FAILED LOGIN (1) on '/dev/tty1' FOR 'root', Authentication failure
        ├ s00-raw
        |       ├ 🟢 crowdsecurity/non-syslog (+5 ~8)
        |       └ 🔴 crowdsecurity/syslog-logs
        ├ s01-parse
        |       ├ 🔴 crowdsecurity/apache2-logs
        |       ├ 🔴 crowdsecurity/mysql-logs
        |       ├ 🔴 crowdsecurity/nextcloud-logs
        |       └ 🔴 crowdsecurity/sshd-logs
        └-------- parser failure 🔴

[LaurenceJJones]

login

No because that event came from login which is not ssh normally that means a user failed sudo password

Just for more clarity within auth.log all authentication attempts are logged we only cover sshd

Jan 20 00:13:07 vs1 login[732]

<timestamp> <hostname> <program>[<pid>]

If it helps

[m0urs]

I am sorry, yes, you are fully right. These were connection attempts from the KVM console .

Here is a line which should trigger this log search term:

SSHD_INVALID_USER: 'Invalid user\s*%{USERNAME:sshd_invalid_user}? from %{IP_WORKAROUND:sshd_client_ip}( port \d+)?'

echo "Jan 20 18:15:04 vs1 sshd[26596]: Invalid user mohamadshah from 8.219.113.255 port 35260" | cscli explain --type sshd -f -
WARN[20-01-2024 21:57:08] Line 0/1 is missing evt.StrTime. It is most likely a mistake as it will prevent your logs to be processed in time-machine/forensic mode.
line: Jan 20 18:15:04 vs1 sshd[26596]: Invalid user mohamadshah from 8.219.113.255 port 35260
       ├ s00-raw
       |       ├ 🟢 crowdsecurity/non-syslog (+5 ~8)
       |       └ 🔴 crowdsecurity/syslog-logs
       ├ s01-parse
       |       ├ 🔴 crowdsecurity/apache2-logs
       |       ├ 🔴 crowdsecurity/mysql-logs
       |       ├ 🔴 crowdsecurity/nextcloud-logs
       |       └ 🟢 crowdsecurity/sshd-logs (+6 ~1)
       ├ s02-enrich
       |       ├ 🔴 crowdsecurity/dateparse-enrich
       |       ├ 🟢 crowdsecurity/geoip-enrich (+13)
       |       ├ 🔴 crowdsecurity/http-logs
       |       ├ 🔴 crowdsecurity/nextcloud-whitelist
       |       └ 🟢 crowdsecurity/whitelists (unchanged)
       ├-------- parser success 🟢
       ├ Scenarios
               ├ 🟢 crowdsecurity/ssh-bf
               ├ 🟢 crowdsecurity/ssh-bf_user-enum
               ├ 🟢 crowdsecurity/ssh-slow-bf
               └ 🟢 crowdsecurity/ssh-slow-bf_user-enum

So it seems to work. My fault was that I used "ssh" as type but it should be "sshd".

So the only open question would be, what does this warning message mean:

Line 0/1 is missing evt.StrTime. It is most likely a mistake as it will prevent your logs to be processed in time-machine/forensic mode.

Is this something I have to worry about?

Apache parsing does work as well. I made the same mistake. The type should not be "apache" but "apache2". In this case it does work and now I do not get that "evt.StrTime" error anymore:

line: 37.139.53.60 - - [20/Jan/2024:22:01:54 +0100] "POST /wp-comments-post.php HTTP/1.0" 302 5564 "https://www.urspringer.de/2006/04/14/voip-und-die-fritzbox-fon-wlan-7170/#comment-8838/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36" - urspringer.de:443
        ├ s00-raw
        |       ├ 🟢 crowdsecurity/non-syslog (+5 ~8)
        |       └ 🔴 crowdsecurity/syslog-logs
        ├ s01-parse
        |       └ 🟢 crowdsecurity/apache2-logs (+21 ~2)
        ├ s02-enrich
        |       ├ 🟢 crowdsecurity/dateparse-enrich (+2 ~2)
        |       ├ 🟢 crowdsecurity/geoip-enrich (+13)
        |       ├ 🟢 crowdsecurity/http-logs (+7)
        |       ├ 🟢 crowdsecurity/nextcloud-whitelist (unchanged)
        |       └ 🟢 crowdsecurity/whitelists (unchanged)
        ├-------- parser success 🟢
        ├ Scenarios

[LaurenceJJones]

Line 0/1 is missing evt.StrTime. It is most likely a mistake as it will prevent your logs to be processed in time-machine/forensic mode.

This warning message means the line did not have the date/time parsed out of the line so when using forensics mode CrowdSecs alternative mode other than live (which is the standard) it mans it can't properly separate the incoming timestamps correctly and wont treat the line properly.

However, one caveat of the warning message is that it shows when the line is not parsed at all which is correct so can lead to confusion that the warning is the cause of the line not being parsed but it is not.

[LaurenceJJones]

Closing issue as completed, and opened a docs issue to clarify it more