CrowdSec - lightweight and collaborative security engine

Ok!

So it seems to work as expected now.

For information, the cURL call does not depend on any WordPress plugin or cache settings, so it’s weird that it works now (returns null if there is no decision for the tested IP) and wasn’t before (returns nothing).

I let this issue open if you find something new 🙂

I will close it later.

Thanks

Hi,
I think we should try to make the Live mode work first (Stream Mode off).

The cURL test is a good start :
1) Create a fake decision for some IP : cscli decisions add --ip 1.2.3.4 --duration 2h --type ban

2) This cURL call should retrieve a result:
curl -H "X-Api-Key: ***" http://localhost:8080/v1/decisions?ip=1.2.3.4

You should have a result like:
[{"duration":"1h59m17.846736476s","id":1,"origin":"cscli","scenario":"manual 'ban' ","scope":"Ip","type":"ban","value":"1.2.3.4"}]

If not, there is something wrong with the crowdsec agent.

If you have a result, we will have to find what is going wrong with the plugin.

Please try the “Test Connection” button (Stream Mode OFF) and see if you have a result or some error in logs. If there is no logs in the plugin log directory, maybe you could find something interestion in the apache logs or nginx logs (depending on what you are using).

Thanks

Hi,

Thanks for you message.

Yes, you should see a message saying if bouncing has been executed succesfully or not.

I guess (as in your Stream Mode Error issue ), that something goes wrong with your request.

As in the Stream Mode Error issue, I suggest you to try with Curl and also to enable the debug log (Advanced -> Enable debug mode)

Thanks

Hi,
I guess I can close this issue.

Thanks

Hi,
It seems that with your configuration the IP that is in the X-Forwarded-For header and the IP that is in the $_SERVER['REMOTE_ADDR'] are the same. That is why the log shows the same value for original_ip and x_forwarded_for_ip.

But this should not be an issue and if there is any active decision for the logged IP, it should work.

Can you check that there is an active decision for the logged IP ?

To check if there is an active decision for an IP a.b.c.d you can run

cscli decisions list -i a.b.c.d

For example, when your log says :

{"type":"NON_AUTHORIZED_X_FORWARDED_FOR_USAGE","original_ip":"3.89.116.106","x_forwarded_for_ip":"3.89.116.106"}

can you look at the result of

cscli decisions list -i 3.89.116.106

If there is no active decision, then this normal that the result of log is “bypass”.

If there is an active decision, please let me know as we should not get a “bypass” then.

Furthermore, in order to debug what could happen, you should find a log message starting with "type":"BOUNCER_INIT" in the debug.log file (if you set the debug log setting to true).
This line contains your plugin settings : could you share it here ?

Thanks

• This reply was modified 3 years, 6 months ago by CrowdSec - lightweight and collaborative security engine.

Hi,
Thanks for your message.
This log message :
{"type":"NON_AUTHORIZED_X_FORWARDED_FOR_USAGE","original_ip":"188.75.5.3","x_forwarded_for_ip":"188.75.5.3"}
makes me think that your proxy IP is 188.75.5.3 and that this IP has not been whitelisted as a trusted IP.

Thus, the bouncer is trying to bounce the 188.75.5.3 IP and, as there is no active decision for this specific IP, it is not blocked.

Please try to add this IP to the trusted IPs in the WordPress plugin setting :

Advanced → Remediations → Trust these CDN IPs (or Load Balancer, HTTP Proxy)

Thanks

Hi,
Thanks for your message.

When I look your log message, I see that Ips that were trying to access your website were 46.54.xxx.xxx and 82.155.xxx.xxx.

Does those IPs has an active decisions on your CrowdSec LAPI ?

To know which decisions are active, you could run “cscli decisions list” on the server where your CrowdSec agent has been installed.

Thanks

Hi,

Thanks for your message.

This error is related to the “Trust these CDN IPs
(or Load Balancer, HTTP Proxy)” in the Advanced settings.

I don’t know why but, for some reason, it seems that you have no value for this setting in your database.

I will work on a new release to correct this bug but, as a workaround for now, you can:
– set a value in the field and save (for example set 1.2.3.4)
– remove the value and save again

Please let me know if it is ok after that.

Thanks

• This reply was modified 3 years, 9 months ago by CrowdSec - lightweight and collaborative security engine.
• This reply was modified 3 years, 9 months ago by CrowdSec - lightweight and collaborative security engine.