Hello 
Yes, everything is installed on the same machine (I added something in the previous message while you were answering)
If both are installed on the same machine, i think that the firewall bouncer will block the IP before it access your PHP process.
For the vendor/ i still think that this is a composer problem. But without error message i can’t help sorry 
I miss read, but if the cs-php-bouncer was not able to install correctly that could be the problem.
If you can copy/paste the output of the install.sh script of the bouncer it could help. And an output of composer install also can help.
Thank you for your quick response! Ok so I have to uninstall the firewall then? Can’t I set the priority of these bouncers so that the php bouncer detects the ip first?
What I don’t understand is that I indicate correctly to crowdsec during a manual seizure that I want a captcha to be generated, so if we assume that during an automatic attack the firewall acts first, ok, but when it’s a manual seizure, I don’t understand …
I don’t think there are any error messages other than the one I provided for the vendor, if it hasn’t happened to anyone else maybe it’s related specifically to a configuration on my side I don’t know it’s strange
Here is the output of compose install, if needed I can uninstall it and reinstall it if you think it is relevant.
nfo from https://repo.packagist.org : #StandWithUkraine
Using version ^0.16.0 for crowdsec/bouncer
./composer.json has been updated
Running composer update crowdsec/bouncer
Loading composer repositories with package information
Update of dependencies
Nothing to change in the lock file
Install dependencies from lock file (including require-dev)
Nothing to install, update or remove
Generation of autoload files
16 packages you use are looking for funding.
Use the `composer fund` command to find out more!
And the classic bouncer install output below.
crowdsec-php-bouncer installed successfully!
Please set the owner of '/usr/local/php/crowdsec/' to www-data or to your webserver owner.
You can do it with:
sudo chown www-data /usr/local/php/crowdsec/
Add the "php_value auto_prepend_file '/usr/local/php/crowdsec/crowdsec-php-bouncer.php'" to your .htacess file. And reload your webserver.
@alteredCoder I put here other information that you never know could be useful
● crowdsec.service - Crowdsec agent
Loaded: loaded (/lib/systemd/system/crowdsec.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2022-03-15 16:46:43 UTC; 52min ago
Process: 402519 ExecStartPre=/usr/bin/crowdsec -c /etc/crowdsec/config.yaml -t (code=exited, status=0/SUCCESS)
Main PID: 402524 (crowdsec)
Tasks: 10 (limit: 2302)
Memory: 72.4M
CPU: 27.415s
CGroup: /system.slice/crowdsec.service
└─402524 /usr/bin/crowdsec -c /etc/crowdsec/config.yaml
Mar 15 16:46:40 vps systemd[1]: Starting Crowdsec agent...
Mar 15 16:46:43 vps systemd[1]: Started Crowdsec agent.
root@vps:/home/arawaks/true_cs_php/cs-php-bouncer# systemctl status crowdsec-firewall-bouncer
● crowdsec-firewall-bouncer.service - The firewall bouncer for CrowdSec
Loaded: loaded (/etc/systemd/system/crowdsec-firewall-bouncer.service; disabled; vendor preset: enabled)
Active: active (running) since Tue 2022-03-15 16:42:28 UTC; 57min ago
Main PID: 377929 (crowdsec-firewa)
Tasks: 7 (limit: 2302)
Memory: 22.5M
CPU: 23.908s
CGroup: /system.slice/crowdsec-firewall-bouncer.service
└─377929 /usr/sbin/crowdsec-firewall-bouncer -c /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml
Mar 15 16:42:26 vpssystemd[1]: crowdsec-firewall-bouncer.service: Succeeded.
Mar 15 16:42:26 vps systemd[1]: Stopped The firewall bouncer for CrowdSec.
Mar 15 16:42:26 vps systemd[1]: crowdsec-firewall-bouncer.service: Consumed 13.278s CPU time.
Mar 15 16:42:26 vps systemd[1]: Starting The firewall bouncer for CrowdSec...
Mar 15 16:42:26 vps crowdsec-firewall-bouncer[377924]: time="2022-03-15T16:42:26Z" level=info msg="crowdsec-firewall-bouncer v0.0.22-debian-pragmatic-f64e94b59a948717c3dc848f9abebb27b9747"
Mar 15 16:42:26 vps-crowdsec-firewall-bouncer[377929]: time="2022-03-15T16:42:26Z" level=info msg="crowdsec-firewall-bouncer v0.0.22-debian-pragmatic-f64e94b59948717c3dc88fabeb27b5974714"
Mar 15 16:42:28 vps-systemd[1]: Started The firewall bouncer for CrowdSec.
cscli bouncers list
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
NAME IP ADDRESS VALID LAST API PULL TYPE VERSION
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
FirewallBouncer-1647255745 127.0.0.1 ✔️ 2022-03-15T17:39:38Z crowdsec-firewall-bouncer v0.0.22-debian-pragmatic-f64e94b59a948717c3dc848f9abebb27b5974714
crowdsec-php-bouncer-9aaxHuNg 127.0.0.1 ✔️ 2022-03-14T13:57:36Z Standalone CrowdSec PHP v0.13.30
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
cscli collections list
COLLECTIONS
------------------------------------------------------------------------------------------------------------
NAME 📦 STATUS VERSION LOCAL PATH
------------------------------------------------------------------------------------------------------------
crowdsecurity/apache2 ✔️ enabled 0.1 /etc/crowdsec/collections/apache2.yaml
crowdsecurity/linux ✔️ enabled 0.2 /etc/crowdsec/collections/linux.yaml
crowdsecurity/sshd ✔️ enabled 0.2 /etc/crowdsec/collections/sshd.yaml
crowdsecurity/base-http-scenarios ✔️ enabled 0.5 /etc/crowdsec/collections/base-http-scenarios.yaml
------------------------------------------------------------------------------------------------------------
cat /etc/crowdsec/
acquis.yaml collections/ console.yaml local_api_credentials.yaml online_api_credentials.yaml patterns/ scenarios/
bouncers/ config.yaml hub/ notifications/ parsers/ profiles.yaml simulation.yaml
cat /etc/crowdsec/profiles.yaml
name: crawler_captcha_remediation
filters:
- Alert.Remediation == true && Alert.GetScenario() in ["crowdsecurity/http-crawl-non_statics", "crowdsecurity/http-bad-user-agent"]
decisions:
- type: captcha
duration: 4h
on_success: break
name: default_ip_remediation
debug: true
filters:
- Alert.Remediation == true && Alert.GetScope() == "Ip"
decisions:
- type: ban
duration: 4h
notifications:
- slack_default # Set the webhook in /etc/crowdsec/notifications/slack.yaml before enabling this.
- splunk_default # Set the splunk url and token in /etc/crowdsec/notifications/splunk.yaml before enabling this.
- http_default # Set the required http parameters in /etc/crowdsec/notifications/http.yaml before enabling this.
- email_default # Set the required http parameters in /etc/crowdsec/notifications/email.yaml before enabling this.
on_success: break
cat /usr/local/php/crowdsec/
crowdsec-php-bouncer-refresh.php crowdsec-php-bouncer.php settings.php vendor/
ls -l /usr/local/php/crowdsec/
total 16
-rw-r--r-- 1 www-data root 301 Mar 15 17:35 crowdsec-php-bouncer-refresh.php
-rw-r--r-- 1 www-data root 306 Mar 15 17:35 crowdsec-php-bouncer.php
-rw-r--r-- 1 www-data root 2198 Mar 15 17:35 settings.php
drwxr-xr-x 13 www-data root 4096 Mar 15 17:35 vendorI just disabled the firewall, I suspect it’s an expected behavior but even without it I can’t display the captcha, this was to try to rule out the firewall acting faster than the php bouncer
Hello, can you try to reinstall the bouncer with the --apache argument for the install script please?
This is what I already did several times yesterday unfortunately, anyway, I followed your instructions here is the return of the command
crowdsec-php-bouncer installed successfully!
Please set the owner of '/usr/local/php/crowdsec/' to www-data or the owner of your web server.
You can do this with :
sudo chown www-data /usr/local/php/crowdsec/
crowdsec_apache configuration apache2 enabled
And reload the apache2 service
sudo systemctl reload apache2
If it’s easier, a discord user suggested me to put nginx in reverse proxy with apache and to see if this way the bouncer works
Hello, i manage to reproduce the issue. I will try to see what is going on and will get back to you
super thank you very much
Hello @arawaks ,
Can you try to git pull the repository and reinstall the bouncer please?
(We have fixed the issue)
So I am posting herewith the result of the orders.
git pull https://github.com/crowdsecurity/php-cs-bouncer.git
hint : Tirer sans spécifier comment réconcilier les branches divergentes est
hint : découragé. Vous pouvez étouffer ce message en exécutant l'une des commandes suivantes
hint : suivant un certain temps avant votre prochain pull :
hint :
hint : git config pull.rebase false # fusionner (la politique par défaut)
hint : git config pull.rebase true # rebase
hint : git config pull.ff only # avance rapide uniquement
hint :
hint : Vous pouvez remplacer "git config" par "git config --global" pour définir une préférence par défaut.
hint : préférence par défaut pour tous les dépôts. Vous pouvez également passer --rebase, --no-rebase,
hint : ou --ff-only sur la ligne de commande pour remplacer la préférence par défaut définie par l'invocation de
hint : invocation.
distant : Énumération d'objets : 1986, complet.
remote : Comptage d'objets : 100% (1040/1040), terminé.
distant : Compression d'objets : 100% (651/651), terminé.
distant : Total 1986 (delta 660), réutilisé 679 (delta 361), pack réutilisé 946
Réception d'objets : 100% (1986/1986), 619.68 KiB | 12.39 MiB/s, terminé.
Résolution des deltas : 100% (1195/1195), terminé.
Depuis https://github.com/crowdsecurity/php-cs-bouncer
* Branche HEAD -> FETCH_HEAD
fatal : refus de fusionner des historiques non liés
I uninstalled my old version of the bouncer, ran a pull in the folder that works properly, then reinstalled the bouncer the output is as follows:
./install.sh --apache
Installation de crowdsec-php-bouncer
crowdsec-php-bouncer a été installé avec succès !
Veuillez définir le propriétaire de '/usr/local/php/crowdsec/' à www-data ou au propriétaire de votre serveur web.
Vous pouvez le faire avec :
sudo chown www-data /usr/local/php/crowdsec/
crowdsec_apache configuration apache2 activée
Et recharger le service apache2
sudo systemctl reload apache2
For the moment alas still nothing, we see here in fact that during an attack this one ban just after the captcha I think it can come from there in parte.
| 405450 | crowdsec | Ip:92.223.89.134 | crowdsecurity/http-sensitive-files | ban | LU | 0 | 5 | 3h58m32.81843238s | 93 |
Ip:92.223.89.134 | crowdsecurity/http-sensitive-files | ban | LU | 0 | 5 | 3h58m32.81843238s | 93 |
| 405449 | crowdsec | Ip:92.223.89.134 | crowdsecurity/http-crawl-non_statics | captcha
Because on the other hand when I manually ban a user by specifying that I want the captcha to be the test to use I still do not have any.
Here is also a ls apache has the rights.
ls -l /usr/local/php/crowdsec/
total 16
-rw-r--r-- 1 www-data root 301 Mar 17 10:23 crowdsec-php-bouncer-refresh.php
-rw-r--r-- 1 www-data root 306 Mar 17 10:23 crowdsec-php-bouncer.php
-rw-r--r-- 1 www-data root 2198 Mar 17 10:23 settings.php
drwxr-xr-x 13 www-data root 4096 Mar 17 10:23 vendor
Hi @arawaks,
Just before digging into decisions.
Following your git pull result. Are you sure the git pull goes well ?
It seems you don’t have the right repository. Here the PHP bouncer repo : GitHub - crowdsecurity/cs-php-bouncer: CrowdSec bouncer for PHP Website
Linked in the documentation : PHP Bouncer | CrowdSec
@he2ss The version I have comes from an old installation that I had done and it worked correctly, unfortunately it seems that when I use the official repository this one does not download correctly because the /vendor folder does not download.
~/cs-php-bouncer$ ./upgrade.sh
Upgrading crowdsec-php-bouncer
[sudo] password for arawaks:
cp: cannot stat 'vendor/': No such file or directory
PHP Bouncer upgraded sucessfully
And here is the one I have from a previous installation
/true_cs_php$ cd cs-php-bouncer/
arawaks@vps:~/true_cs_php/cs-php-bouncer$ ./upgrade.sh
Upgrading crowdsec-php-bouncer
[sudo] password for arawaks:
PHP Bouncer upgraded sucessfully
However, it seems that when I install the plugin, it can’t connect to the local interface
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
NAME IP ADDRESS VALID LAST API PULL TYPE VERSION
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
FirewallBouncer-1647255745 127.0.0.1 ✔️ 2022-03-17T14:35:40Z crowdsec-firewall-bouncer v0.0.22-debian-pragmatic-f64e94b59a948717c3dc848f9abebb27b5974714
crowdsec-php-bouncer-i7QYBDD2 ✔️ 2022-03-17T14:31:53Z
-----------------------------------------------------------------------------------------------------------------------------------------
So I copied and pasted the vendor folder that I had in the folder that works to copy it to a repository where I’m sure the address is good (given your comment) there I have an ip on the bouncer that appears, but it continues to ban me instead of showing the captcha.
I also notice that I don’t even have a message that appears saying that I was banned with the little smile.
I am however well and truly banned when I try to attack the site, but nothing happens if I manually navigate in sensitive areas of the site (like the authentication menu of the admin)
crowdsec-php-bouncer-i7QYBDD2 127.0.0.1 ✔️ 2022-03-17T14:31:53Z Standalone CrowdSec PHP v0.16.0
Bouncer
Again apache has the rights for /usr/local/php/crowdsec and I put the right stuff in the .htaccess of the site.So I don’t understand
EDIT : I have just reinstalled everything locally on a totally virgin vm, I don’t know if it comes from the recent modifications of the repository but the famous vendor folder is present from the beginning (well once the installation is launched on compose of course)! Anyway, on paper everything looks ok and on the first try.
Even the php bouncer found the local address correctly the first time.
But in spite of the authorizations given to apache, the call of the php script in the .htaccess as well as the condtions added in the crowdsec profile (neither more nor less than what is specified in the doc) still no captcha on my side.
Maybe there is something I’m doing wrong? But I sincerely don’t see what
Would the bouncer-php have been more optimized to work with nginx?
Good news for the installation part.
For the captcha, could you please list again your decisions and paste also your profiles.yaml file.
Hello @he2ss ,
Here is the return of the requested orders
Here I tested manually and no captcha although the cache is emptied, and during an attack this one ban just after the captcha so necessarily nothing appears
Even if that I think it can be fixed by indicating the right parameters in profiles.yaml, but I prefer to wait for your advice to be sure that we are all on the same wavelength
cscli decisions list
+--------+----------+-------------------+----------------------------------------------------+---------+---------+----+--------+--------------------+----------+
| ID | SOURCE | SCOPE:VALUE | REASON | ACTION | COUNTRY | AS | EVENTS | EXPIRATION | ALERT ID |
+--------+----------+-------------------+----------------------------------------------------+---------+---------+----+--------+--------------------+----------+
| 545766 | crowdsec | Ip:45.83.90.147 | crowdsecurity/http-sensitive-files | ban | | 0 | 5 | 3h58m46.502918823s | 115 |
| 545765 | crowdsec | Ip:45.83.90.147 | crowdsecurity/http-crawl-non_statics | captcha | | 0 | 45 | 3h58m45.377596668s | 114 |
| 534141 | cscli | Ip:45.128.133.228 | manual 'captcha' from | captcha | | | 1 | 54m24.97803092s | 111 |
| | | | '1927516e0ce84581b64327cd590d79bcDGWJU2VHVzt8u3gm' | | | | | | |
+--------+----------+-------------------+----------------------------------------------------+---------+---------+----+--------+--------------------+----------+
root@vps:/var/www/aseaction.backup# cat /etc/crowdsec/profiles.yaml
name: crawler_captcha_remediation
filters:
- Alert.Remediation == true && Alert.GetScenario() in ["crowdsecurity/http-crawl-non_statics", "crowdsecurity/http-bad-user-agent"]
decisions:
- type: captcha
duration: 4h
on_success: break
---
name: default_ip_remediation
#debug: true
filters:
- Alert.Remediation == true && Alert.GetScope() == "Ip"
decisions:
- type: ban
duration: 4h
# notifications:
# - slack_default # Set the webhook in /etc/crowdsec/notifications/slack.yaml before enabling this.
# - splunk_default # Set the splunk url and token in /etc/crowdsec/notifications/splunk.yaml before enabling this.
# - http_default # Set the required http parameters in /etc/crowdsec/notifications/http.yaml before enabling this.
# - email_default # Set the required http parameters in /etc/crowdsec/notifications/email.yaml before enabling this.
on_success: break
You need to be sure which IP are you adding in decisions for captcha and if this IP is the one used to do the query (to test the captcha).
Also, may be you should take a look also at the error.log to see if the bouncer didn’t log any error (for example if the bouncer isn’t able to connect to the LAPI or another error).
@he2ss Yes I am sure of the ip used, and by conscience not denying that I too can be sure of a thing and then be wrong, I reattack with another and check several times to be sure the ip is good, and there is strictly nothing in errors.log of apache.
To hide nothing from you there were two lines precisely but that have no relation with our problem.
Lines like this: [Fri Mar 18 09:55:24.277158 2022] [authz_core:error] [pid 831666] [client 138.246.253.24:57496] AH01630: client denied by server configuration: /var/www/nextcloud/robots.txt
Which was not a problem of crowdsec configuration because apache has all the rights (I checked again) but simply because I had placed in my vhost a require all denied depending on x or y ip.
I obviously removed these lines, and since then everything is back in order on this side. But it didn’t solve our problem which is not surprising since I don’t think it’s related.
The other message I see in the logs is this one.
[Fri Mar 18 08:49:52.036647 2022] [php7:warn] [pid 831618] [client 45.128.133.228:35338] PHP Warning: session_write_close(): Failed to write session data using user defined save handler. (session.save_path: /var/lib/php/sessions) in /var/www/aseaction/libraries/vendor/joomla/session/src/Storage/NativeStorage.php on line 114
I have to do more research on this problem but at first sight it has no direct relationship with our problem. Now obviously I can be wrong and if it is the case mea culpa
But this message appeared this morning and hasn’t reappeared at all since then, even though the services have been restarted since then in order to make sure that x or y changes have been taken into account (such as crowdsec’s decisions). Even though I suspect that restarting the services is not useful, I sometimes do it from time to time just in case, but without any effect of course.
Small details that I think I have not detailed. I have two sites one that is on a classic domain name and the other that is in subdomain. The site that is linked to the sub domain does not have a certificate. (I will put one on him only Sunday) what makes that currently this subdomain is not accessible to the navigators which do not accept the http.
I’m telling you this in case it could have any relation, and I insist on the fact that for the first site everything is ok on this side because it has a certificate.
EDIT : @alteredCoder @he2ss I completely forgot to tell you (I told bui on discord) but I can’t even log in to the different sites in the administration interface.
The identifiers are good I am persuaded of it, moreover when one is mistaken of id a message indicates to me that the account does not exist or that the password is incorrect, which does not arrive when I seize the good identifiers.
In fact nothing happens when this happens. And it comes from the php bouncer because when I deactivate it I have access to the interface again.
Here is a screen of the top of the two situations (functional and non-functional, the same messages are generated, with the difference that many more pages are generated when the access works (I could not take all the results of the pages but they all have a code 200 for the functional page, except the 301 at the very beginning)
I think the problem might be related because something seems to block the pages when it doesn’t work, so that might be what’s blocking the captchas
And I looked at the logs again (especially errors.log) and nothing strange appeared, not even those mentioned above.
Well, I took my backup where the captcha works, except that I do not know why and on principle I initially wanted to understand but so much the worse.
Here on the other hand similar problem and on this installation is on the other I still can not log in, as described above.
I have this time this displayed in the logs.
[php7:error] [pid 589] [client 66.249.69.148:35620] PHP Fatal error: Uncaught Error: Wrong parameters for CrowdSecBouncerException([string $message [, long $code [, Throwable $previous = NULL]]) in /usr/local/php/crowdsec/vendor/crowdsec/bouncer/src/StandAloneBounce. php:359\nStack trace:\n#0 /usr/local/php/crowdsec/vendor/crowdsec/bouncer/src/StandAloneBounce.php(359): Exception->__construct()\n#1 [internal function]: CrowdSecBouncerStandAloneBounce->CrowdSecBouncer()\n#2 /usr/local/php/crowdsec/vendor/crowdsec/bouncer/src/RestClient.php(105): file_get_contents()\n#3 /usr/local/php/crowdsec/vendor/crowdsec/bouncer/src/ApiClient.php(56): CrowdSecBouncer->request()\n#4 /usr/local/php/crowdsec/vendor/crowdsec/bouncer/src/ApiCache.php(534): CrowdSecBouncer/ApiClient->getFilteredDecisions()\n#5 /usr/local/php/crowdsec/vendor/crowdsec/bouncer/src/ApiCache.php(573): CrowdSecBouncer/ApiCache->miss()\n#6 /usr/local/php/crowdsec/vendor/crowdsec/bouncer/src/Bouncer.php(115): CrowdSecBouncer->get()\n#7 /usr/local/php/crowdsec/vendor/crowdsec/bouncer/src/Abst in /usr/local/php/crowdsec/vendor/crowdsec/bouncer/src/StandAloneBounce.php on line 359