Closed codiflow closed 5 months ago
@codiflow: Thanks for opening an issue, it is currently awaiting triage.
In the meantime, you can:
The only services which send regular requests to 127.0.0.1 on my server are monit, nginx as reverse proxy and connections to the mysql server. So maybe triggering
crowdsecurity/http-bad-user-agent
on 127.0.0.1 somehow reproduces this?
Hmmm are you using any upstream servers that you take the forwarded remote IP as a header? such as cloudflare for example?
We have been floating the idea but this would mean a hardcoded cidr list for 127.0.0.1/8
and ::1/128
as there both loopbacks. I will forward this too the team.
I would be interested if we can see the context around the ban just so we can look for there is a wl issue?
Could you run these commands:
cscli alerts list
Find the Alert ID from the table then run:
cscli alerts inspect <id> -d
[!NOTE] Replace
<id>
with the ID
This will provide all context are the loopback being banned as the scenario is quite concerning.
There you go:
################################################################################################
- ID : 12741
- Date : 2024-06-19T13:23:48Z
- Machine : REDACTED
- Simulation : false
- Reason : crowdsecurity/http-bad-user-agent
- Events Count : 2
- Scope:Value : Ip:127.0.0.1
- Country :
- AS :
- Begin : 2024-06-19 13:23:44.761388285 +0000 UTC
- End : 2024-06-19 13:23:48.531502038 +0000 UTC
- UUID : a1f4f724-56d7-40ed-944a-c3735b4e4181
- Context :
╭────────────┬──────────────────────────────────────────────────────────────╮
│ Key │ Value │
├────────────┼──────────────────────────────────────────────────────────────┤
│ method │ GET │
│ status │ 403 │
│ target_uri │ //wp-admin/setup-config.php?step=1 │
│ target_uri │ //wordpress/wp-admin/setup-config.php?step=1 │
│ user_agent │ Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) │
│ │ AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 │
│ │ Chrome/60.0.3112.107 Moblie Safari/537.36 │
╰────────────┴──────────────────────────────────────────────────────────────╯
- Events :
- Date: 2024-06-19 15:23:44 +0200 +0200
╭─────────────────┬──────────────────────────────────────────────────────────────╮
│ Key │ Value │
├─────────────────┼──────────────────────────────────────────────────────────────┤
│ datasource_path │ /var/log/apache2/other_vhosts_access.log │
│ datasource_type │ file │
│ http_args_len │ 6 │
│ http_path │ //wp-admin/setup-config.php?step=1 │
│ http_status │ 403 │
│ http_user_agent │ Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) │
│ │ AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 │
│ │ Chrome/60.0.3112.107 Moblie Safari/537.36 │
│ http_verb │ GET │
│ log_type │ http_access-log │
│ service │ http │
│ source_ip │ 127.0.0.1 │
│ target_fqdn │ 127.0.1.1 │
│ timestamp │ 2024-06-19T15:23:44+02:00 │
╰─────────────────┴──────────────────────────────────────────────────────────────╯
- Date: 2024-06-19 15:23:48 +0200 +0200
╭─────────────────┬──────────────────────────────────────────────────────────────╮
│ Key │ Value │
├─────────────────┼──────────────────────────────────────────────────────────────┤
│ datasource_path │ /var/log/apache2/other_vhosts_access.log │
│ datasource_type │ file │
│ http_args_len │ 6 │
│ http_path │ //wordpress/wp-admin/setup-config.php?step=1 │
│ http_status │ 403 │
│ http_user_agent │ Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) │
│ │ AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 │
│ │ Chrome/60.0.3112.107 Moblie Safari/537.36 │
│ http_verb │ GET │
│ log_type │ http_access-log │
│ service │ http │
│ source_ip │ 127.0.0.1 │
│ target_fqdn │ 127.0.1.1 │
│ timestamp │ 2024-06-19T15:23:48+02:00 │
╰─────────────────┴──────────────────────────────────────────────────────────────╯
Looks like these requests came in via nginx and port 80 – this are the access log entries from the corresponding nginx log (see the typos "Mozlila" and "Moblie" in the user agent string):
┌104.248.159.240 - - [19/Jun/2024:15:23:43 +0200] "GET //wp-admin/setup-config.php?step=1 HTTP/1.1" 301 162 "www.google.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36" │
└104.248.159.240 - - [19/Jun/2024:15:23:45 +0200] "GET //wordpress/wp-admin/setup-config.php?step=1 HTTP/1.1" 301 162 "www.google.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36"
These requests came in via nginx and were redirected to apache2 on the same machine (I know, weird setup but it should not cause those kind of problems) which hosts one specific application. The nginx configuration looks like this:
[...]
location / {
default_type text/html;
proxy_redirect off;
proxy_set_header Host $http_host;
proxy_set_header X-REQUEST_URI $request_uri;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# CHANGE-SERVER-PORT-HERE
proxy_pass http://127.0.0.1:8089;
client_max_body_size 50m;
client_body_buffer_size 256k;
proxy_connect_timeout 120;
proxy_send_timeout 90;
proxy_read_timeout 180;
proxy_buffer_size 4k;
proxy_buffers 16 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
}
The apache2 access log looks like this:
127.0.1.1:80 127.0.0.1 - - [19/Jun/2024:15:23:44 +0200] "GET //wp-admin/setup-config.php?step=1 HTTP/1.0" 403 363 "www.google.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36"
127.0.1.1:80 127.0.0.1 - - [19/Jun/2024:15:23:48 +0200] "GET //wordpress/wp-admin/setup-config.php?step=1 HTTP/1.0" 403 363 "www.google.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36"
So the "double reverse proxy" seems to be the issue here :/
But shouldn't the crowdsec whitelist prevent such situations?
There you go:
################################################################################################ - ID : 12741 - Date : 2024-06-19T13:23:48Z - Machine : REDACTED - Simulation : false - Reason : crowdsecurity/http-bad-user-agent - Events Count : 2 - Scope:Value : Ip:127.0.0.1 - Country : - AS : - Begin : 2024-06-19 13:23:44.761388285 +0000 UTC - End : 2024-06-19 13:23:48.531502038 +0000 UTC - UUID : a1f4f724-56d7-40ed-944a-c3735b4e4181 - Context : ╭────────────┬──────────────────────────────────────────────────────────────╮ │ Key │ Value │ ├────────────┼──────────────────────────────────────────────────────────────┤ │ method │ GET │ │ status │ 403 │ │ target_uri │ //wp-admin/setup-config.php?step=1 │ │ target_uri │ //wordpress/wp-admin/setup-config.php?step=1 │ │ user_agent │ Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) │ │ │ AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 │ │ │ Chrome/60.0.3112.107 Moblie Safari/537.36 │ ╰────────────┴──────────────────────────────────────────────────────────────╯ - Events : - Date: 2024-06-19 15:23:44 +0200 +0200 ╭─────────────────┬──────────────────────────────────────────────────────────────╮ │ Key │ Value │ ├─────────────────┼──────────────────────────────────────────────────────────────┤ │ datasource_path │ /var/log/apache2/other_vhosts_access.log │ │ datasource_type │ file │ │ http_args_len │ 6 │ │ http_path │ //wp-admin/setup-config.php?step=1 │ │ http_status │ 403 │ │ http_user_agent │ Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) │ │ │ AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 │ │ │ Chrome/60.0.3112.107 Moblie Safari/537.36 │ │ http_verb │ GET │ │ log_type │ http_access-log │ │ service │ http │ │ source_ip │ 127.0.0.1 │ │ target_fqdn │ 127.0.1.1 │ │ timestamp │ 2024-06-19T15:23:44+02:00 │ ╰─────────────────┴──────────────────────────────────────────────────────────────╯ - Date: 2024-06-19 15:23:48 +0200 +0200 ╭─────────────────┬──────────────────────────────────────────────────────────────╮ │ Key │ Value │ ├─────────────────┼──────────────────────────────────────────────────────────────┤ │ datasource_path │ /var/log/apache2/other_vhosts_access.log │ │ datasource_type │ file │ │ http_args_len │ 6 │ │ http_path │ //wordpress/wp-admin/setup-config.php?step=1 │ │ http_status │ 403 │ │ http_user_agent │ Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) │ │ │ AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 │ │ │ Chrome/60.0.3112.107 Moblie Safari/537.36 │ │ http_verb │ GET │ │ log_type │ http_access-log │ │ service │ http │ │ source_ip │ 127.0.0.1 │ │ target_fqdn │ 127.0.1.1 │ │ timestamp │ 2024-06-19T15:23:48+02:00 │ ╰─────────────────┴──────────────────────────────────────────────────────────────╯
Looks like these requests came in via nginx and port 80 – this are the access log entries from the corresponding nginx log (see the typos "Mozlila" and "Moblie" in the user agent string):
┌104.248.159.240 - - [19/Jun/2024:15:23:43 +0200] "GET //wp-admin/setup-config.php?step=1 HTTP/1.1" 301 162 "www.google.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36" │ └104.248.159.240 - - [19/Jun/2024:15:23:45 +0200] "GET //wordpress/wp-admin/setup-config.php?step=1 HTTP/1.1" 301 162 "www.google.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36"
These requests came in via nginx and were redirected to apache2 on the same machine (I know, weird setup but it should not cause those kind of problems) which hosts one specific application. The nginx configuration looks like this:
[...] location / { default_type text/html; proxy_redirect off; proxy_set_header Host $http_host; proxy_set_header X-REQUEST_URI $request_uri; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # CHANGE-SERVER-PORT-HERE proxy_pass http://127.0.0.1:8089; client_max_body_size 50m; client_body_buffer_size 256k; proxy_connect_timeout 120; proxy_send_timeout 90; proxy_read_timeout 180; proxy_buffer_size 4k; proxy_buffers 16 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; }
The apache2 access log looks like this:
127.0.1.1:80 127.0.0.1 - - [19/Jun/2024:15:23:44 +0200] "GET //wp-admin/setup-config.php?step=1 HTTP/1.0" 403 363 "www.google.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36" 127.0.1.1:80 127.0.0.1 - - [19/Jun/2024:15:23:48 +0200] "GET //wordpress/wp-admin/setup-config.php?step=1 HTTP/1.0" 403 363 "www.google.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36"
So the "double reverse proxy" seems to be the issue here :/
But shouldn't the crowdsec whitelist prevent such situations?
Yes the whitelist should, but the file you linked was inside the hub folder that doesn't mean it is active. Could you provide the output of cscli parsers list
Seems like my own whitelist "overrides" the default one? 🤯
INFO Ignoring file /etc/crowdsec/parsers/s02-enrich/whitelists.yaml of type parsers
INFO Ignoring file /etc/crowdsec/hub/parsers/s02-enrich/crowdsecurity/whitelists.yaml of type parsers
PARSERS
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Name 📦 Status Version Local Path
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
crowdsecurity/apache2-logs ✔️ enabled 1.4 /etc/crowdsec/parsers/s01-parse/apache2-logs.yaml
crowdsecurity/dateparse-enrich ✔️ enabled 0.2 /etc/crowdsec/parsers/s02-enrich/dateparse-enrich.yaml
crowdsecurity/geoip-enrich ✔️ enabled 0.4 /etc/crowdsec/parsers/s02-enrich/geoip-enrich.yaml
crowdsecurity/http-logs ✔️ enabled 1.2 /etc/crowdsec/parsers/s02-enrich/http-logs.yaml
crowdsecurity/mysql-logs ✔️ enabled 0.4 /etc/crowdsec/parsers/s01-parse/mysql-logs.yaml
crowdsecurity/nginx-logs ✔️ enabled 1.5 /etc/crowdsec/parsers/s01-parse/nginx-logs.yaml
crowdsecurity/sshd-logs ✔️ enabled 2.3 /etc/crowdsec/parsers/s01-parse/sshd-logs.yaml
crowdsecurity/syslog-logs ✔️ enabled 0.8 /etc/crowdsec/parsers/s00-raw/syslog-logs.yaml
crowdsecurity/whitelists 🏠 enabled,local /etc/crowdsec/parsers/s02-enrich/custom-internal-whitelist.yaml
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
I just followed the instructions from the documentation like stated here: https://docs.crowdsec.net/docs/v1.4.0/whitelist/create/
Didn't know that this kicks out the default one 😅
Seems like my own whitelist "overrides" the default one? 🤯
INFO Ignoring file /etc/crowdsec/parsers/s02-enrich/whitelists.yaml of type parsers INFO Ignoring file /etc/crowdsec/hub/parsers/s02-enrich/crowdsecurity/whitelists.yaml of type parsers PARSERS ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── Name 📦 Status Version Local Path ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── crowdsecurity/apache2-logs ✔️ enabled 1.4 /etc/crowdsec/parsers/s01-parse/apache2-logs.yaml crowdsecurity/dateparse-enrich ✔️ enabled 0.2 /etc/crowdsec/parsers/s02-enrich/dateparse-enrich.yaml crowdsecurity/geoip-enrich ✔️ enabled 0.4 /etc/crowdsec/parsers/s02-enrich/geoip-enrich.yaml crowdsecurity/http-logs ✔️ enabled 1.2 /etc/crowdsec/parsers/s02-enrich/http-logs.yaml crowdsecurity/mysql-logs ✔️ enabled 0.4 /etc/crowdsec/parsers/s01-parse/mysql-logs.yaml crowdsecurity/nginx-logs ✔️ enabled 1.5 /etc/crowdsec/parsers/s01-parse/nginx-logs.yaml crowdsecurity/sshd-logs ✔️ enabled 2.3 /etc/crowdsec/parsers/s01-parse/sshd-logs.yaml crowdsecurity/syslog-logs ✔️ enabled 0.8 /etc/crowdsec/parsers/s00-raw/syslog-logs.yaml crowdsecurity/whitelists 🏠 enabled,local /etc/crowdsec/parsers/s02-enrich/custom-internal-whitelist.yaml ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Yes, if you use the same name key it will override whatever node was previously parsed so the names need to be unique. I am going to create a change to update all documentation to use a non used name so if you copy and paste it wont break everything.
We will most likely in 2.0
version of CrowdSec make this an error as we wont want to run if the user makes this type of configuration.
Plus also I would look at the apache2 configuration to make sure it gets the remote IP address from the correct headers as currently it seems it logging all at localhost.
Yes, if you use the same name key it will override whatever node was previously parsed so the names need to be unique.
Really good to know – couldn't derive that from the docs 😅
Plus also I would look at the apache2 configuration to make sure it gets the remote IP address from the correct headers as currently it seems it logging all at localhost.
Will look into it, thanks for the hint.
So we can close this as it was an issue by "misconfiguration" due to misleading documentation and not a bug.
TL;DR
Make sure you are using a custom name for your whitelist (e.g. crowdsecurity/whitelists-custom
) otherwise the default whitelist (crowdsecurity/whitelists
) will be overridden by your custom whitelist.
You can check the lists being used by issuing the following command: cscli parsers list
Thanks 🙏
What happened?
I'm using crowdsec on many servers for more than a year now and there were no problems with blacklisting – until today. During the day parts of my server were unavailable and I couldn't find any reason for this.
Looking deeper into my crowdsec Telegram log I found out that Crowdsec blocked itself (127.0.0.1) and therefore prevented any action with
cscli
as those requests are sent to 127.0.0.1 as well:From my perspective this should be prevented by default as it is very very unlikely that there is a real threat incoming from
127.0.0.1
. This would mean the machine itself is not trustworthy anymore.I found
127.0.0.1
being listed in/etc/crowdsec/hub/parsers/s02-enrich/crowdsecurity/whitelists.yaml
so I really don't know how this could happen if the IP itself is listed there.What did you expect to happen?
It is not possible that crowdsec blacklists 127.0.0.1 by default.
How can we reproduce it (as minimally and precisely as possible)?
The only services which send regular requests to 127.0.0.1 on my server are monit, nginx as reverse proxy and connections to the mysql server. So maybe triggering
crowdsecurity/http-bad-user-agent
on 127.0.0.1 somehow reproduces this?Anything else we need to know?
I never had this issue ever before on one of my machines and they all share the same configuration.
I tried to temporarily "resolve" this by replacing all occurences of 127.0.0.1 in the configuration files with 127.0.1.1, restarting crowdsec and then trying to remove the 127.0.0.1 ban.
This was the output of
cscli decisions list
(it worked)Removal with
cscli decisions delete -i 127.0.0.1
did not work:I needed to "chain" both commands to make the deletion of the decision possible:
systemctl restart crowdsec.service crowdsec-firewall-bouncer.service ; cscli decisions delete -i 127.0.0.1
Crowdsec version
OS version
Enabled collections and parsers
Acquisition config
Config show
Prometheus metrics
Related custom configs versions (if applicable) : notification plugins, custom scenarios, parsers etc.