Is my setup working

1

Hi
I am wondering if my setup is correct as I am not seeing any bans for few days
image
image

image
image1858×274 30.4 KB

image

2

crowdsec
crowdsec1423×734 132 KB

3

Hello @amahhou !

Let’s check your metrics to see what is going on, and we’ll review it in the processing order :

image
image1038×194 86.7 KB

From the acquisition point of view:

  • You have two apache logs : one that produced only 36 lines (probably an error log ?) that haven’t been parsed, and the main one (probably an access log ?) that has produced 4.3K lines. 100% of those lines are parsed (as you can see LINES PARSED == LINES READ) so this is good. Furthermore, you can see that 2.1K of those lines were poured to bucket. It mean that they are not only parsed, but they even end up being poured to scenarios LINES BEING POURED TO BUCKET
  • Your kern.log and message.log is mostly unparsed but it’s ok as you don’t have any specific parsers or scenarios for that
  • Then you have your auth.log that has a lot of events (68K) but that aren’t parsed. If it’s supposed to be mostly ssh logs, you might have an issue here.

So on the acquisition aspect it seems ok, except the fact that auth.log has a lot of unparsed logs.

From the parsers point of view:
image

What is relevant here is to check the ratio of PARSED to UNPARSED.
Keep in mind that crowdsec only tries to parse what is relevant to its scenarios, so having UNPARSED messages isn’t alarming.

From the buckets point of view:

image
image827×186 95 KB

  • What is surprising is that you have so little ssh-bruteforce (ssh-bf & ssh-bf_user-enum), but it might explain as well why there are so many unparsed lines in your auth.log. Any chance that you sshd isn’t publicly exposed ?
  • The http-* scenarios seems to be ok, you can see that they were instanciated and poured (it means that some events elligible for this happened), they simply didn’t overflow
  • Your main source of alerts seems to be postfix-spam

Overall, it seems to be OK from what I see in the metrics, can you just confirm that you don’t expose ssh publicly ?

4

Thank you for your reply it’s very clear

In my Auth.log I have some entries i wish i could parse

Nov 3 14:51:38 proftpd: pam_unix(proftpd:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/ftpd27769 ruser=www-data rhost=36.89.55.95 user=www-data

What should I do to fix the statement below
/etc/systemd/system/crowdsec.service:6: PIDFile= references path below legacy directory /var/run/, updating /var/run/crowdsec.pid → /run/crowdsec.pid; please update the unit file accordingly.

saslauthd[722]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=

5

Hey,

Glad this helped :slight_smile:

Regarding your question for :

Nov 3 14:51:38 proftpd: pam_unix(proftpd:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/ftpd27769 ruser=www-data rhost=36.89.55.95 user=www-data

We need to create a proftpd collection for this, with a parser (for logs) and a scenario (to detect such attacks), it doesn’t exist for now : https://github.com/crowdsecurity/hub/issues/43

If you are looking to create such a collection, please let me know I will gladly give you a hand !

And for :

/etc/systemd/system/crowdsec.service:6: PIDFile= references path below legacy directory /var/run/, updating /var/run/crowdsec.pid → /run/crowdsec.pid; please update the unit file accordingly.

I think it will be fixed in the coming release :slight_smile: