ecran securite blocked by firewall

Dev
1

Hello,
I have a SPIP site where I have the following html displayed:

image
image2560×1393 232 KB

It is because, this is what is currently also shown when loading from certain browsers, IPs, the ecran_securite.php source file:
https://git.spip.net/spip-contrib-outils/securite/-/raw/master/ecran_securite.php

This file is normally downloaded via cronjob, using e.g.
wget « Error 403: Forbidden »

That is a horrible idea when there is a firewall: The result is that the firewall’s html is added to every SPIP website.

The documentation does not offer a specific way in which to load:

So I believe there are many ways people are loading the file, and this can create issues.

For critical projects, I have followed the forum’s advise and I use the following script:

#!/usr/bin/env bash

#ecran securite
ecran_securite_file_path="/var/www/master/config/ecran_securite.php"

ecran_securite_content_git=$(wget -qO -\
    'https://git.spip.net/api/v4/projects/spip-contrib-outils%2Fsecurite/repository/files/ecran_securite.php?ref=master' \
)

ecran_securite_content_sha=$( jq -r  '.content_sha256' <<< "${ecran_securite_content_git}" )
ecran_securite_content_encoded=$( jq -r  '.content' <<< "${ecran_securite_content_git}" )
ecran_securite_content_decoded=$(echo "${ecran_securite_content_encoded}" | base64 --decode - )
ecran_securite_content_decoded_sha=$(echo -n "${ecran_securite_content_decoded}" | sha256sum | head -c 64)

if [[ "${ecran_securite_content_sha}" == "${ecran_securite_content_decoded_sha}" ]]; then
    echo -n "${ecran_securite_content_decoded}" > "${ecran_securite_file_path}"
#    exit 0
fi

But this is not very convenient and also requires jq as dependency.

The issue is perhaps not simple to fix. Turning off the firewall for that route could be good. Or hosting it statically elsewhere. Or we recommend people to not use wget.

Or that SPIP handles this by itself. But again, if it makes a http request, it could fail in the same way, and then ecran_securite will not update.

Should this be added to the core, in a way in which it cannot fail? I am thinking a SPIP tache/cron. Instead of needing to set this up separately.

Sorry I am just reporting an issue here without a (simple) solution.
Urs

2

In courteau suisse / Swiss Army Knive,
the ecran_securite feature is also broken:

image
image1163×418 35.5 KB

Then click on [Actualiser]:
image
image1172×365 47.9 KB

This will only happen from IPs of e.g. shared hostings that are blocked by the firewall of gitlab, I believe.

3

Yes, we need to tunes some parts to let valid users and scripts pass, but ai-crawler and bots is a really pain. We try to find some mitigations but it’s not that simple.

Note that if you use Composer to install or get this script, it should pass.

Spip Core doesn’t provide code for downloading ecran_securite.php as we don’t provide signature to prove that the good file is downloaded without error : this was a longtime todo but nobody has done it. By the way « ecran_securite.php » isn’t the best way to provide security : you should update your SPIP instead.

4

Yes, not easy problem!

It would be amazing if ecran_security.php would have a signature.
Is there already a key that could be used to generate the signature?
openssl would be good here, or gpg but it may not be available on all hosts.
Then to validate, openssl_verify is probably best as it’s part of php itself.

It would also help automatically against corrupted files e.g. by anubis blocking the request but returing html, or a 404 from gitlab appearing if the URL ever changes. It would be amazing if we could have an endpoint like spip.net/raw/ecran_securite.php or something, that will always forward to the right point. How easy would it be to DDOS a static file?

I would be happy to support somehow, e.g. also updating the documentation to offer cronjob commands that implement the checking, to prevent this issue for others.

I agree updating is needed always, but SPIP stands as the last CMS that can be used by solopreneurs, and we do need holidays sometimes. Whatever can be handled with ecran_securite does a lot of good to all spip developers. I think it’s one of the things that make SPIP stand out from a security perspective as well.

5

This file will no longer be shipped with SPIP in the next major release.

in SPIP4.4, as @marcimat said, you can update this file via composer update spip/security (may be in 4.3, don’t remember as it is no longer supported). Remember it’s been 9 months since its last release.

For older versions, I know a lot of people want it to be maintained. You should ask them how they figure out with those kind of problems you tell. There ?

We had a bunch of static files hosted by www.spip.net in the past, but we finally stopped this and moved the spip_loader.php script to get.spip.net where it is easier to manage static files. But there are many other possibilities.

6

Hello @JamesRezo,
I didn’t know ecran_securite will be retired.
For me it was a strong element of SPIP, buying us devs a bit more time before hackers exploit CVEs.
Of course it is not always (and quite often recently it seems) not possible to make fixes through ecran_securite. And anyway it’s an additional workload and effort to maintain this.
But I always found it the most elegant solution and service to keep the sites from getting hacked when there’s not someone able to patch within days (and now hours…).
So I still think it’s relevant and good to know it is ongoing for SPIP 4.
Maybe it can be revisited with SPIP 5? If there is an exploit that can be patched with it.

7

Hello @ursrig

It is retired but partially replaced by spip-league / guard · GitLab. A more extensible component. You should take a look for spip_waf in SPIP5, i suppose.

8

Ok great, glad to read this!

It this looks very interesting indeed, great to see a fix for the « stupid » type bot that’s are not necessarily « malicious » when it comes to paginations and combining parameters creating endless traffic:

I’ve seen this too when having ajax events on a page that also has a pagination. Very annoying. I had my own fix active, good this is handled by SPIP itself soon!

A cronjob pulling in the guard would then load new rules that could eventually be written to prevent exploits.

9

Hi Urs,

FTR this was already present in ecran_securite for SPIP 4 cf ecran_securite.php · master · spip-contrib-outils / securite · GitLab :wink:

1 « J'aime »