Ubuntu-fr

Jpaul78

[Résolu] interdire l'accès à un répertoire d'un site web sous apache

Bonjour,

Je tente de restreindre l'accès au un répertoire /var/www/YesWiki/private/backups de mon serveur apache.
J'ai fait différentes manipulations et je suis un peu perdu.

Ma version de serveur est : 

sudo apache2ctl -v
Server version: Apache/2.4.52 (Ubuntu)
Server built:   2024-04-10T17:45:18

J'ai commencé par tenter d'ajouter un fichier .htaccess contenant DENY FROM ALL (comme l'indiquait la doc de YesWiki) avant de comprendre qu'avec apache 2.4 il fallait utiliser Require all denied.
Mais ça ne faisait toujours rien.

Ensuite, j'ai modifié /etc/apache2/apache2.conf pour ajouter (après différents tests, ceci est l'état actuel) :

<Directory /var/www/YesWiki/private/backups>
        AllowOverride None
        Require all denied
</Directory>

Toujours pas de changement.

Puis je me suis aperçu qu'il y avait un autre fichier de configuration : /etc/apache2/sites-enabled/000-default.conf
J'ai fait la même modification, j'ai toujours le même problème (j'ai bien relancé le serveur apache à chacun de mes tests).

Ma première question est pourquoi deux fichiers de configuration, lequel dois-je modifier (j'aurais tendance à penser que c'est : /etc/apache2/sites-enabled/000-default.conf mais je ne suis sûr de rien) ?

Merci d'avance pour vos réponses, cordialement,
Jean-Paul

--
Modération : balises [ code ] ajoutées.

Dernière modification par Jpaul78 (Le 17/04/2024, à 15:44)

krodelabestiole

Re : [Résolu] interdire l'accès à un répertoire d'un site web sous apache

je te conseille de commencer par lire la doc concernant les hôtes virtuels pour comprendre ce que tu fais : https://doc.ubuntu-fr.org/apache2#hotes_virtuels

si tu veux plus d'info il faudrait nous donner tes virtualhost (entre balises <code !)

et sinon tu ne peux pas mettre ton backup ailleurs si tu n'as pas besoin de le servir sur le web ?

---

nouveau forum ubuntu-fr on en parle là : refonte du site / nouveau design
profil - sujets récurrents - sources du site

Jpaul78

Re : [Résolu] interdire l'accès à un répertoire d'un site web sous apache

Merci pour cette réponse et le lien.
Ceci dit, je ne comprends toujours pas pourquoi j'ai un fichier /etc/apache2/apache2.conf puisque d'après la doc, c'est bien /etc/apache2/sites-enabled/000-default.conf qui est pris en compte.
Voici le contenu de mon fichier /etc/apache2/sites-available/000-default.conf

<VirtualHost *:80>
        # The ServerName directive sets the request scheme, hostname and port that
        # the server uses to identify itself. This is used when creating
        # redirection URLs. In the context of virtual hosts, the ServerName
        # specifies what hostname must appear in the request's Host: header to
        # match this virtual host. For the default virtual host (this file) this
        # value is not decisive as it is used as a last resort host regardless.
        # However, you must set it for any further virtual host explicitly.
        #ServerName www.example.com

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        <Directory /var/www/YesWiki/private/backups>
                AllowOverride None
                Require all denied
        </Directory>

        # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
        # error, crit, alert, emerg.
        # It is also possible to configure the loglevel for particular
        # modules, e.g.
        #LogLevel info ssl:warn

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        # For most configuration files from conf-available/, which are
        # enabled or disabled at a global level, it is possible to
        # include a line for only one particular virtual host. For example the
        # following line enables the CGI configuration for this host only
        # after it has been globally disabled with "a2disconf".
        #Include conf-available/serve-cgi-bin.conf
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Et voici celui de /etc/apache2/sites-available/default-ssl.conf

<IfModule mod_ssl.c>
        <VirtualHost _default_:443>
                ServerAdmin webmaster@localhost

                DocumentRoot /var/www/html

                # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
                # error, crit, alert, emerg.
                # It is also possible to configure the loglevel for particular
                # modules, e.g.
                #LogLevel info ssl:warn

                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined

                # For most configuration files from conf-available/, which are
                # enabled or disabled at a global level, it is possible to
                # include a line for only one particular virtual host. For example the
                # following line enables the CGI configuration for this host only
                # after it has been globally disabled with "a2disconf".
                #Include conf-available/serve-cgi-bin.conf

                #   SSL Engine Switch:
                #   Enable/Disable SSL for this virtual host.
                SSLEngine on

                #   A self-signed (snakeoil) certificate can be created by installing
                #   the ssl-cert package. See
                #   /usr/share/doc/apache2/README.Debian.gz for more info.
                #   If both key and certificate are stored in the same file, only the
                #   SSLCertificateFile directive is needed.
                SSLCertificateFile      /etc/ssl/certs/ssl-cert-snakeoil.pem
                SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

                #   Server Certificate Chain:
                #   Point SSLCertificateChainFile at a file containing the
                #   concatenation of PEM encoded CA certificates which form the
                #   certificate chain for the server certificate. Alternatively
                #   the referenced file can be the same as SSLCertificateFile
                #   when the CA certificates are directly appended to the server
                #   certificate for convinience.
                #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt

                #   Certificate Authority (CA):
                #   Set the CA certificate verification path where to find CA
                #   certificates for client authentication or alternatively one
                #   huge file containing all of them (file must be PEM encoded)
                #   Note: Inside SSLCACertificatePath you need hash symlinks
                #                to point to the certificate files. Use the provided
                #                Makefile to update the hash symlinks after changes.
                #SSLCACertificatePath /etc/ssl/certs/
                #SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt

                #   Certificate Revocation Lists (CRL):
                #   Set the CA revocation path where to find CA CRLs for client
                #   authentication or alternatively one huge file containing all
                #   of them (file must be PEM encoded)
                #   Note: Inside SSLCARevocationPath you need hash symlinks
                #                to point to the certificate files. Use the provided
                #                Makefile to update the hash symlinks after changes.
                #SSLCARevocationPath /etc/apache2/ssl.crl/
                #SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl

                #   Client Authentication (Type):
                #   Client certificate verification type and depth.  Types are
                #   none, optional, require and optional_no_ca.  Depth is a
                #   number which specifies how deeply to verify the certificate
                #   issuer chain before deciding the certificate is not valid.
                #SSLVerifyClient require
                #SSLVerifyDepth  10

                #   SSL Engine Options:
                #   Set various options for the SSL engine.
                #   o FakeBasicAuth:
                #        Translate the client X.509 into a Basic Authorisation.  This means that
                #        the standard Auth/DBMAuth methods can be used for access control.  The
                #        user name is the `one line' version of the client's X.509 certificate.
                #        Note that no password is obtained from the user. Every entry in the user
                #        file needs this password: `xxj31ZMTZzkVA'.
                #   o ExportCertData:
                #        This exports two additional environment variables: SSL_CLIENT_CERT and
                #        SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
                #        server (always existing) and the client (only existing when client
                #        authentication is used). This can be used to import the certificates
                #        into CGI scripts.
                #   o StdEnvVars:
                #        This exports the standard SSL/TLS related `SSL_*' environment variables.
                #        Per default this exportation is switched off for performance reasons,
                #        because the extraction step is an expensive operation and is usually
                #        useless for serving static content. So one usually enables the
                #        exportation for CGI and SSI requests only.
                #   o OptRenegotiate:
                #        This enables optimized SSL connection renegotiation handling when SSL
                #        directives are used in per-directory context.
                #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
                <FilesMatch "\.(cgi|shtml|phtml|php)$">
                                SSLOptions +StdEnvVars
                </FilesMatch>
                <Directory /usr/lib/cgi-bin>
                                SSLOptions +StdEnvVars
                </Directory>

                #   SSL Protocol Adjustments:
                #   The safe and default but still SSL/TLS standard compliant shutdown
                #   approach is that mod_ssl sends the close notify alert but doesn't wait for
                #   the close notify alert from client. When you need a different shutdown
                #   approach you can use one of the following variables:
                #   o ssl-unclean-shutdown:
                #        This forces an unclean shutdown when the connection is closed, i.e. no
                #        SSL close notify alert is send or allowed to received.  This violates
                #        the SSL/TLS standard but is needed for some brain-dead browsers. Use
                #        this when you receive I/O errors because of the standard approach where
                #        mod_ssl sends the close notify alert.
                #   o ssl-accurate-shutdown:
                #        This forces an accurate shutdown when the connection is closed, i.e. a
                #        SSL close notify alert is send and mod_ssl waits for the close notify
                #        alert of the client. This is 100% SSL/TLS standard compliant, but in
                #        practice often causes hanging connections with brain-dead browsers. Use
                #        this only for browsers where you know that their SSL implementation
                #        works correctly.
                #   Notice: Most problems of broken clients are also related to the HTTP
                #   keep-alive facility, so you usually additionally want to disable
                #   keep-alive for those clients, too. Use variable "nokeepalive" for this.
                #   Similarly, one has to force some clients to use HTTP/1.0 to workaround
                #   their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
                #   "force-response-1.0" for this.
                # BrowserMatch "MSIE [2-6]" \
                #               nokeepalive ssl-unclean-shutdown \
                #               downgrade-1.0 force-response-1.0

        </VirtualHost>
</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Encore merci.
Jean-Paul

krodelabestiole

Re : [Résolu] interdire l'accès à un répertoire d'un site web sous apache

il faut lire la doc :

les fichiers de configuration globale apache2.conf, envars et ports.conf n'ont pas à être modifiés.
Ces fichiers généraux sont susceptibles d'être écrasés lors d'une mise à jour majeure de son système, et on perd dans ce cas sa configuration personnalisée

4. Fichiers de configuration

ensuite tu verras qu'avec AllowOverride None ton fichier .htaccess ne sera pas pris en compte : 7. .htaccess

tu n'as pas créé ni personnalisé de virtualhost ?

---

nouveau forum ubuntu-fr on en parle là : refonte du site / nouveau design
profil - sujets récurrents - sources du site

krodelabestiole

Re : [Résolu] interdire l'accès à un répertoire d'un site web sous apache

concernant le simple contrôle d'accès : https://httpd.apache.org/docs/current/f … ccess.html

---

nouveau forum ubuntu-fr on en parle là : refonte du site / nouveau design
profil - sujets récurrents - sources du site

bruno

Re : [Résolu] interdire l'accès à un répertoire d'un site web sous apache

Bonjour,

En plus des bons conseils déjà donnés, il faut penser à relancer Apache après chaque modification de la configuration :

sudo systemctl restart apache2

Et a priori ceci :

        DocumentRoot /var/www/html
        <Directory /var/www/YesWiki/private/backups>
                AllowOverride None
                Require all denied
        </Directory>

ne sert strictement à rien puisque le répertoire /var/www/YesWiki/private/backups est en dehors du dossier racine du site  /var/www/html, donc inaccessible via HTTP(S)

Jpaul78

Re : [Résolu] interdire l'accès à un répertoire d'un site web sous apache

Merci infiniment,

Effectivement, mon problème venait bien du fait qu'il manquait le sous répertoire html  dans le chemin d'accès du répertoire à protéger.
J'ai la fâcheuse tendance, quand je relis, à voir ce que j'ai voulu mettre et pas ce qui est écris.
Merci à krodelabestiole pour m'avoir permis de confirmer que le fichier /etc/apache2/apache2.conf ne doit pas être modifié et à bruno pour cet œil extérieur qui a mis en évidence mon problème.

Cordialement,
Jean-Paul