logo article ou rubrique
le serveur apache
petit tour d’horizon simplifié

Internet désigne l’interconnexion mondiale de réseaux, permettant à des milliards d’équipements disséminés dans le monde de communiquer.
Le Web, de son côté, désigne le système hypertexte constitué de l’ensemble des pages desservies par les serveurs HTTP de par le monde.
la doc en français :
https://httpd.apache.org/docs/2.4/fr/getting-started.html


par lagrenouille

 

 

* Le serveur HTTP est le premier et le plus connu des projets, mais la fondation Apache va bien plus loin que cela, et gère d’autres projets d’envergure. serveur LDAP, * OpenOffice.org, SpamAssassin, Subversion, Tomcat....
*Apache supporte – bien évidemment – le protocole sécurisé HTTPS, qui permet de chiffrer les communications afin d’en empêcher la lecture par un tiers. Ce support est disponible avec le module mod_ssl .
 
Un serveur web est un logiciel permettant à des clients, d’accéder à des pages web, c’est-à-dire en réalité des fichiers au format HTML à partir d’un navigateur, ce navigateur est votre client web.
Un serveur web est donc un « simple » logiciel capable d’interpréter les requêtes HTTP arrivant sur le port associé au protocole HTTP (par défaut sur le port 80), et de fournir une réponse avec ce même protocole.
 
HTTP (HyperText Transfer Protocol) est un protocole de communication entre un client et un serveur développé pour
le Web. L’une de ses fonctions principales est ainsi de récupérer des pages Web.

* Quand on ouvre une URL en http://, le navigateur va agir comme un client HTTP. Il va donc envoyer une requête HTTP.
Le serveur HTTP renvoie une réponse HTTP qui contient la page Web demandée.Le navigateur interprète alors la page Web et l’affiche.
Le client : c’est le visiteur d’un site Web. Il demande la page Web au serveur.
vous êtes des clients quand vous surfez sur le Web
c’est votre navigateur Web qui est le client, car c’est lui qui demande la page Web.
Les serveurs : ce sont les ordinateurs qui délivrent les sites Web aux internautes (aux clients)

* Apache possède désormais de nombreuses fonctionnalités dont la possibilité de définir une configuration spécifique à chaque fichier ou répertoire partagé, ainsi que de définir des restrictions d’accès grâce aux fichiers htaccess.
 
Toutes les fonctionnalités d’Apache2 sont implémentées sous forme de modules. Certains d’entre eux sont simplement compilés directement dans apache de manière statique. Pour en connaître la liste, il suffit d’exécuter apache2 avec l’option -l :
 
* les Modules du serveur apache, c’est ici : *
http://httpd.apache.org/docs/2.4/mod/
 
* httpd est le programme du serveur HTTP d’Apache. Il a été conçu pour fonctionner sous forme de processus démon indépendant. Lorsqu’il est utilisé ainsi, il va créer un jeu de processus enfants ou de threads qui traiteront les requêtes.
il n’est pas invoqué directement, mais plutôt via apachectl
c’est L’installation d’Apache2 qui crée automatiquement l’utilisateur, par défaut www-data.
 
plusieurs commandes sont disponibles pour changer ler droits.chgrp. chown, chmod et voir les acl.
La commande « chgrp » est utilisée pour changer le groupe de fichier ou de répertoire. Ceci est une commande d’admin root. Seul cet utilisateur peut changer les attributs/processus du fichier.
chgrp -R votre-groupe /var/www/html
La syntaxe est
chgrp -cfR nouveaugroup nomfichier/chemin repertoire
dans la commande chgrp C’est le -R qui le rend récursif
- c change l’autorisation pour chaque fichier
- f Forcer. De pas rapporter les erreurs.
 

 
Apache peut également être utilisé comme proxy ou comme reverse proxy.
Lire la doc à ce sujet.
Un proxy permet de centraliser et éventuellement filtrer les accès à Internet au sein d’un réseau ; cela permet par exemple de mutualiser les ressources et de servir de cache au niveau du réseau, en ne chargeant une même image qu’une seule fois, même pour plusieurs clients.
Un reverse proxy, c’est la même logique côté serveur ; c’est un serveur qui reçoit les requêtes des clients et qui les redirige vers un ou plusieurs serveurs web, tout en cachant les données qu’il peut, afin de limiter la charge sur les serveurs web eux-mêmes.
 

* Mon serveur apache en local *

 
* Le serveur apache, sans en voir toute la configuration, car c’est assez complexe et vaste, possédant beaucoup de modules,lui permettant de très nombreuses fonctionnalités.
* Je vais faire un petit tour d’horizon très simplifié.
 
* Commençons par l’installation de mon petit serveur perso. comment, quoi et pourquoi, sachant qu j’utilise les CMS spip et wordpress .

 

 
 

  • L’installation de mes sites, je les installerai dans un répertoire que je nomme web, ensuite, je ferai des liens symbolique vers /var/www/html
    - je mets ensuite les droits à 770, excepté quelques fichiers de spip à l’installation qui requièrent 777 .

- Pour que apache puisse écrire sur les fichiers, le groupe doit appartenir à www-data
- Puis je m’ajoute user www-data avec la commande adduser.
pour vérifier si vous êtes bien enregistré : tapez dans votre terminal.
 

 

  • Il faut configurer un VirtualHost par site et les activer.
     
    La configuration d’Apache utilise des balises sous la forme
     
    <...>,  / , </...>
    <VirtualHost *:80> ou voir <VirtualHost *:8390> suivant le port
    DocumentRoot /var/www
    [...]
    </VirtualHost>
    ~
    * Nous définissons donc ici un hôte virtuel. L’argument en ouverture du
    bloc, « *:80 », ou autre port, correspond à l’interface physique et au port sur lequel écouter.

     
    https://httpd.apache.org/docs/2.4/fr/vhosts/examples.html
     
    * Avec Apache, chaque site ou application web correspond en principe à un hôte virtuel (VirtualHost en anglais).
    Chaque hôte virtuel est défini par un fichier de configuration indépendant, qu’on trouve ou qu’on créé dans le répertoire /etc/apache2/sites-available/.
    La majorité de la configuration d’Apache se fait donc dans ces fichiers « sites-available »
     
    Les répertoires mods-enabled et sites-enabled ne contiennent que des liens symboliques vers
    leurs équivalents en *-available .
     
    Les liens symboliques sont gérés par les commandes :
    - a2ensite pour activer un site (apache2 enable site) ;
    - a2dissite pour désactiver un site (apache2 disable site) ;
    - a2enmod pour activer un module (apache2 enable module) ;
    - a2dismod pour désactiver un module (apache2 disablemodule).
    - a2enconf [configuration d’un service à activer]
    - a2disconf [configuration d’un service à désactiver
     
    * Sur Debian, l’hôte virtuel de la configuration par défaut d’Apache2 est dans un fichier 000-default : ces trois zéros lui permettent d’être évalué en premier lieu et de servir d’hôte par défaut.ce fichier qui détermine aussi comment afficher la page « It works !
    * Autrement dit, ne placez pas une application critique et privée dans le
    tout premier hôte virtuel : n’importe qui pourrait y accéder sans même
    connaître son URL !
     
    * le paramètre DocumentRoot , que nous venons de rencontrer, permet de signaler à Apache où il doit chercher les fichiers à desservir.

 
* le fichier php.ini *
 
*Réglage maximale la taille de vos fichiers uploadés sur votre site
modification du fichier php.ini [1]
 
* les fichiers .htaccess *
 
* Les fichiers .htaccess permettent également de définir des contextes :
 
* Avant d’aller plus loin:dans votre conf apache.
* Lorsque la directive AllowOverrideList est définie à None, les fichiers .htaccess sont totalement ignorés. Dans ce cas, le serveur n’essaiera même pas de lire les fichiers .htaccess du système de fichiers.
* AllowOverride None
 
* Lorsque cette directive est définie à All, toute directive valable dans le Contexte .htaccess sera autorisée dans les fichiers .htaccess.
* si il est spécifié AllowOverrideList Redirect RedirectMatch seules les directives Redirect et RedirectMatch sont autorisées. Toutes les autres provoqueront une erreur interne du serveur.
voir pour les les redirections ici :
https://httpd.apache.org/docs/2.4/fr/rewrite/remapping.html
 
* ces fichiers permettent de modifier certains aspects de la configuration d’Apache sans avoir accès aux fichiers de configuration ; c’est très utile sur des serveurs où les webmestres n’ont pas accès au serveur en tant que root : ils peuvent alors définir certains points de configuration de manière indépendante.
* Cependant les fichiers .htacces sons sensible à la casse et parfois il vaut mieux mettre certaines configurations directement dans le fichier apache.
- Les fichiers .htaccess ne doivent être utilisés que si vous n’avez pas accès au fichier de configuration du serveur principal. L’utilisation des fichiers .htaccess ralentit le fonctionnement de votre serveur .
* Il est toujours préférable de définir les directives que vous pouvez inclure dans un fichier .htaccess dans une section Directory, car elles produiront le même effet avec de meilleures performances.

* Les fichiers .htaccess fournissent une méthode pour modifier la configuration du serveur au niveau d’un répertoire. Un fichier, contenant une ou plusieurs directives de configuration, est placé dans un répertoire de documents particulier, et ses directives s’appliquent à ce répertoire et à tous ses sous-répertoires.
* Si je regarde les .htaccess de mon installation "galette" en local, seul localhost est autorisé.(127.0.0.1), le module mod_authz_host. restreint l’accès à certaines parties de votre site web en fonction de l’adresse de l’hôte de vos visiteurs.
* Require all denied signifie que toutes les requêtes sont rejetées
 

 Options -Indexes
 <IfModule mod_authz_core.c>
   Require all denied
 </IfModule>
 <IfModule !mod_authz_core.c>
   Order deny,allow
   Deny from All
   Allow from 127.0.0.1
 </IfModule>

 
* En général, les fichiers .htaccess utilisent la même syntaxe que les fichiers de configuration principaux. Ce que vous pouvez mettre dans ces fichier est déterminé par la directive AllowOverride.
 
* Lire les descriptions des options de vos htaccess
- AllowOverride AuthConfig,
- AllowOverride FileInfo
- AllowOverride Indexes
- AllowOverride Limit

 
* le fichier /etc/apache2/ports.conf définit les ports en écoute.
on retrouve les directives Listen et NameVirtualHost
* Comme éxpliqué dans la doc d’apache, la directive Listen spécifiée dans le fichier de configuration est à sa valeur par défaut de 80 (ou tout autre port inférieur à 1024), il est nécessaire de posséder les privilèges root pour pouvoir démarrer apache, et lui permettre d’être associé à ce port privilégié.
* Lorsque le serveur est démarré, il effectue quelques opérations préliminaires comme ouvrir ses fichiers de log, puis il lance plusieurs processus enfants qui ont pour rôle d’écouter et de répondre aux requêtes des clients. Le processus httpd principal continue à s’exécuter sous l’utilisateur root, tandis que les processus enfants s’exécutent sous un utilisateur aux privilèges restreints. Ceci s’effectue par la voie du Module Multi-Processus (MPM)
 

Listen 80

<IfModule ssl_module>
        Listen 443
</IfModule>

 

  • httpd.conf pour les paramètres spécifiques à
    l’administrateur/au système. généralement, ce fichier est
    vide et inutilisé .
     
    * les processus sont visible avec la commande.
     

* Pour voir tous les modules apache chargés, faites la commande :

 
* Connaître la consommation en ram d’apache

* Pour vérifier la bonne conf de votre vhost

 
*- Pour vérifier et analyser la configuration de vos serveurs virtuels, vous pouvez utiliser
l’argument -S, en root

 

* Divers * * Divers * * Divers * * Divers * * Divers *

 

 
* lorsque l’on saisit l’adresse (URL) d’un site dans un navigateur, une requête « DNS » [2]
transforme cette adresse textuelle (FQDN) en adresse IP numérique. Cette adresse IP est celle de votre machine où réside votre serveur web Apache .
FQDN (Fully Qualified Domain Name )ou (nom de domaine réservé) peut s’appliquer à autant de virtualhost,( d’hôtes virtuels), que vous aurez configuré sous la même ip.
* ."Dans les grandes lignes, lorsque l’on saisit l’adresse (URL) d’un site dans un navigateur, une requête DNS transforme cette adresse textuelle (appelée FQDN, pour Fully Qualified Domain Name) en adresse IP numérique. Cette adresse IP est celle de votre machine où réside le serveur Apache (votre serveur web).
Cette association FQDN/adresse IP n’est pas nécessairement exclusive :
un nombre illimité de FQDN peuvent être associés à une seule et même adresse IP. à partir de là, lorsque votre navigateur web interroge un serveur, il précise le FQDN qu’il recherche et le serveur HTTP - Apache en l’occurrence - est capable de desservir des données différentes
selon le serveur demandé. L’hôte physique est le même, mais il s’agit virtuellement, pour les navigateurs (clients) qui s’y connectent, de serveurs différents : dans la terminologie ’Apache, on parle alors d’« hôtes virtuels ».
Dans le cas de figure le plus courant, on souhaite donc héberger deux sites web ou plus, ayant des adresses (URL) différentes, mais avec une seule interface réseau et une seule adresse IP....."
 

* virtualhost, extrait court des directives de configuration *

 

NameVirtualHost  : indique au serveur web Apache que sur le port 1280 on a l’IP 192.168.1.12
soit : NameVirtualHost 192.168.1.12:1280
.ServerName indique l’URL du site Web hébergé
ServerName localhost
ServerAdmin webmaster@localhost
DocumentRoot permet de signaler à Apache où il doit chercher les fichiers à desservir, En d’autres termes, c’est le répertoire racine du serveur, le répertoire de référence lorsqu’un chemin est relatif (peu importe la directive et l’endroit.
ServerName permet d’identifier précisément l’hôte virtuel, c’est son nom principal.
ServerAlias permet de donner un ou plusieurs noms complémentaires, par lesquels les visiteurs pourront également accéder au site concerné
Timeout 120 c’est, en secondes le temps mort maximal requis entre une émission et une réception, ici 120s.

 

* Les autorisations d’accès
* Les directives Order , Allow et Deny permettent de définir les autorisations
d’accès, selon les éléments fournis par les requêtes (adresses IP, nom d’hôte,
user-agent...) :
* {{Allow}} définit les clients autorisés ;
* {{Deny}} définit les clients interdits ;
* {{Order}} définit l’ordre dans lequel évaluer ces deux directives.
~
* explication tiré de la doc apache2 *
~
* si:
Order Deny,Allow
Deny from all
Allow from example.org

* alors: tous les hôtes du domaine example.org ont l'autorisation d'accès ; tous les autres voient leur accès refusé.
~
* si:
Order Allow,Deny
Allow from example.org
Deny from foo.example.org

* alors: tous les hôtes du domaine example.org ont l'autorisation d'accès, sauf ceux du sous-domaine foo.example.org qui voient leur accès refusé
~
* si:
'<Directory "/www">'
   Order Allow,Deny
</Directory>

* alors: La présence d'une directive Order peut affecter le contrôle d'accès à une partie du serveur même en l'abscence de directives Allow et Deny associées, à cause de son influence sur le statut par défaut. dans ce cas, on interdit tout accès au répertoire /www à cause du statut d'accès par défaut qui est défini à Deny.
*La directive Order ne contrôle l'ordre dans lequel sont traitées les directives d'accès qu'au cours de chaque phase du traitement de la configuration du serveur. Ceci implique, par exemple, qu'une directive Allow ou Deny située dans une section <Location> sera toujours évaluée après une directive Allow ou Deny située dans une section <Directory> ou un fichier .htaccess, sans tenir compte de la définition de la d»irective Order

********************************************
* dans la documentation technique de Debian il est dit: *
********************************************
"La première chose à faire lors de la mise en production d’un serveur Apache est de faire en sorte qu’il n’affiche pas l’ensemble de ses informations de versions afin d’éviter à tout attaquant potentiel de connaître trop d’informations sur sa machine cible."

-Pour cela deux directives sont à modifier.
-Ces deux directives se trouvent dans le fichier /etc/apache2/conf.d/security, que l’on édite :
soit dans /etc/apache2/conf.d/security ou dans etc/apache2/conf-available/security.conf

-si l'on a  
ServerTokens OS
* mis par défaut en général : le serveur affichera Apache, son numéro de version complet et son système d’exploitation Apache/2.0.55 (Debian)
mettre la plus restrictive, Apache ne devrait afficher que Apache ;
ServerTokens Prod

-si l'on a  
ServerTokens OS
* mis par défaut en général : le serveur affichera Apache, son numéro de version complet et son système d’exploitation Apache/2.0.55 (Debian)
mettre
ServerSignature Off
et l'on n’affichera pas ces informations.

On n’oublie pas de recharger la configuration d’Apache
/etc/init.d/apache2 reload
ou
service apache2 reload

 
* Voir plus de détails ici :
https://httpd.apache.org/docs/2.4/fr/sections.html
 
* Bref...
* Je peux donc donc héberger mes deux sites web (spip et wp) voir plus encore, ayant des adresses (URL) différentes, mais avec une seule interface réseau et une seule adresse IP.
 

Des outils pour la surveillance d’apache et les logs d’apache

 
* Tous les services réseau peuvent faire l’objet d’attaques de type "Déni de service" (Denial of Service - DoS)
* Pour empêcher aux services réseaux de répondre correctement aux demandes, les pirates saturent leurs ressource par l’envoie d’énormes envoies de données, difficile de se prémunir de ces attaques, sinon par des pare-feu qui limitent les connexions d’ip ou de réseaux.
Des outils de surveillances et d’audit peuvent faciliter la.source des attaques, ainsi qu des configurations propres au système d’exploitation, La directive RequestReadTimeout permet de limiter le temps que met le client pour envoyer sa requête, ce qui peut être à double tranchant.
* Voir dans les nombreux modules d’apache sil existe des conf qui peuvent minimiser les problèmes de DoS.
* Assurez vous que les utilisateurs n’ait aucun droit pour modifier les configurations, apache c’est à root et à lui seul.
Apache est démarré par l’utilisateur root, puis il devient la propriété de l’utilisateur défini par la directive User afin de répondre aux demandes

* Enfin, maintenez votre serveur à jour, et lisez la doc ici :
 
https://httpd.apache.org/docs/2.4/fr/misc/security_tips.html
 
* Surveillez vos journaux, même si les fichiers journaux ne consignent que des évènements qui se sont déjà produits, ils vous informeront sur la nature des attaques qui sont lancées contre le serveur et vous permettront de vérifier si le niveau de sécurité nécessaire est atteint.
* je parle aussi dans cet article de voir les logs en directe dans une console avec multitail.
 
 

 
*apachetop*

  • Outil de surveillance de Apache en temps réel
    apache top est un utilitaire en temps réel basé sur curses qui affiche des informations à propos d’une copie d’Apache en cours d’exécution.

Il est conçu sur le modèle de l’utilitaire standard « top » et affiche des informations telles que le nombre de requêtes par seconde, le nombre d’octets par seconde et les adresses les plus souvent demandées.

Il doit être lancé à partir d’une machine exécutant Apache car il fonctionne en traitant les fichiers de journaux situés dans /var/log/apache
 

 
*multtail*
 

 
Difficile de comprendre et de traduire les réponses avec :

 
monitoring voir article sur le réseau ici

 
* Apache permet bien sûr d’enregistrer des journaux (logs), afin de tracer d’éventuels problèmes
rencontrés. Mais les possibilités en termes de journalisation vont plus loin ; on peut notamment
personnaliser les journaux relatifs aux requêtes effectuées par les clients.
Ces fonctionnalités sont offertes par les modules mod_log_config , mod_log_debug , mod_
log_forensic et mod_logio .
 
* A propos de l’installation de php *
apt-get install libapache2-mod-php7.0 installera automatiquement MPM Prefork
ce module est directement activé dans Apache 2 ; en effet, la commande
a2enmod php est automatiquement exécutée par le script de post-installation.
 
* Sur Debian Stretch la configuration de PHP se situe dans le répertoire /etc/php/7 . Plus précisément, ce répertoire contient deux sous-répertoires :
→ /etc/php/7.0/cli pour la configuration de la commande PHP utilisée en ligne de commandes,
→ /etc/php/7.0/apache2 pour la configuration de PHP lorsqu’il est utilisé par Apache 2.
* Le répertoire /etc/php/7.0/apache2/conf.d/ contient des fichiers de configuration complémentaires qui sont également chargés.
 
* Ce découpage permet de gérer plus proprement les configurations de chaque module
de PHP., l’interpréteur PHP est lui-même également modulaire.
 
* Quelques modules php parmi tant d’autres
* php7.0-ldap pour interagir avec une base LDAP ;
* php7.0-mysql pour lire ou écrire dans une base MySQL ;
* php7.0-pgsql pour lire ou écrire dans une base PostgreSQL ;
* php7.0-imap pour la gestion des courriers électroniques par IMAP ;
* php7.0-enchant pour la vérification orthographique ;
* php7.0-sqlite pour lire ou écrire dans un fichier SQLite...
* php7.0-gd pour la manipulation des images
* php7.0-bz2 bzip2 module for PHP [default]
* php7.0-cli interpréteur en ligne de commande pour le langage de script PHP
* php7.0-curl CURL module for PHP
* phpmyadmin MySQL web administration tool (graph)
 

 
* Module Multi-Processus (MPM) *
 

 
Le MPM ITK est un module développé de manière indépendante, (c’est-à-dire hors du giron de la fondation Apache) qui permet une séparation de privilèges au niveau des VirtualHosts. Il devient possible de faire fonctionner chacun des hôtes virtuels sous une identité (UID et GID) différente.
MPM veut dire Multi-Processing Module. mpm-ikk vous permet de lancer chacun de vos vhost avec une uid et gid séparé. En d’autres terme, chacun de vos vhost peuvent etre lancés avec un user spécifique sans forcement passer par la configuration de votre serveur apache (qui pour le coup va concerner tous vos vhost de la meme manière).
 
Dès lors, les scripts, les données et les fichiers de configuration d’un hôte virtuel n’ont plus besoin d’être lisibles par les autres. Cela devrait plaire à n’importe quel administrateur oucieux de bien séparer les sites, ou encore à celui devant gérer plusieurs utilisateurs n’ayant rien en commun.
 
* il y’a quelques avantages à utiliser ce module :
* possibilité de lancer un user par vhost
* inutile de modifier la conf apache pour tous les vhost à la fois
* permet d’identifier tous les processus lancés par un user et donc de les fermer d’un coup (pkill -u my_user)
* permet de régler les problèmes de droits d’accès que peut avoir www-data
* permet de limiter les accès d’apache à certains repertoires puisque il sera limité aux droits du user, non plus de www-data
*

 
Si la directive Listen spécifiée dans le fichier de configuration est à sa valeur par défaut de 80 (ou tout autre port inférieur à 1024), il est nécessaire de posséder les privilèges root pour pouvoir démarrer apache, et lui permettre d’être associé à ce port privilégié. Lorsque le serveur est démarré, il effectue quelques opérations préliminaires comme ouvrir ses fichiers de log, puis il lance plusieurs processus enfants qui ont pour rôle d’écouter et de répondre aux requêtes des clients. Le processus httpd principal continue à s’exécuter sous l’utilisateur root, tandis que les processus enfants s’exécutent sous un utilisateur aux privilèges restreints. Ceci s’effectue par la voie du Module Multi-Processus (MPM).
 
* Permissions sur les répertoires de la racine du serveur *
Typiquement, Apache est démarré par l’utilisateur root, puis il devient la propriété de l’utilisateur défini par la directive User afin de répondre aux demandes. Comme pour toutes les commandes exécutées par root, vous devez vous assurer qu’elle n’est pas modifiable par les utilisateurs autres que root. Les fichiers eux-mêmes, mais aussi les répertoires ainsi que leurs parents ne doivent être modifiables que par root.
Si vous permettez à des utilisateurs non root de modifier des fichiers que root écrit ou exécute, vous exposez votre système à une compromission de l’utilisateur root. Par exemple, quelqu’un pourrait remplacer le binaire httpd de façon à ce que la prochaine fois que vous le redémarrerez, il exécutera un code arbitraire. Si le répertoire des journaux a les droits en écriture (pour un utilisateur non root), quelqu’un pourrait remplacer un fichier journal par un lien symbolique vers un autre fichier système, et root pourrait alors écraser ce fichier avec des données arbitraires. Si les fichiers journaux eux-mêmes ont des droits en écriture (pour un utilisateur non root), quelqu’un pourrait modifier les journaux eux-mêmes avec des données fausses.

 

 

 

HTTPS -certificat de sécurité SSL :

 
’<’VirtualHost *:443>
 
* Les hébergeurs comme Gandi, ovh, 1&1 et bien d’autres vous vendent des certificats SSL.
(voir gratuit pour un temps limité..)
* Il existe un certificat gratuit "Let’s Encrypt", renouvelable manuellement ou automatiquement..
* SSL signifie : Secure Sockets Layer, protocole de sécurisation des échanges sur Internet, devenu TLS Transport Layer Security en 2001 .

  • HTTPS signifie : ’HyperText Transfer Protocol Secure, « protocole de transfert hypertexte sécurisé »
     
  • Pour activer HTTPS sur votre site Web, vous devez donc obtenir le certificat à partir d’une autorité de certification (AC ou CA pour Certificate Authority en anglais). Let’s Encrypt est une autorité de certification.
     
    * Le client ACME Certbot peut automatiser la création et l’installation de certificats sans temps d’arrêt. Mode expert pour les braves..
    * Cerbot vous dmandera ce que vous utilisez : Apache, nginx ou autre...ainsi que votre système, debian, archlinux, fedora ou autre..
    * Certbot est destiné à être administré en ligne de commande sur le serveur sur lequel votre (ou vos)site est hébergé.
     

     
    Certbot dispose d’un plugin Apache, qui est supporté sur de nombreuses plates-formes, et automatise l’installation des certificats.

* En exécutant cette commande, vous obtiendrez un certificat et Certbot éditera automatiquement votre configuration Apache pour la servir. Si vous vous sentez plus conservateur et que vous souhaitez modifier manuellement la configuration d’Apache, vous pouvez utiliser la sous-commande certonly :

 
* les certificats Let’s Encrypt durent 90 jours
* Pour automatiser le renouvellement automatique de vos certificats

 

 
* les droits spéciaux sous apache *
 
* Sachant que l’uid (User IDentification) c’est le numéro unique qui identifie l’utilisateurs
le gid (Group IDentification) c’est son group dans un system multi-utilisateur
 

* les setuid, setgid et sticky bit sont des droits dits spéciaux, ils s’ajoutent aux droits classiques (lecture, écriture et exécution) et fonctionnent différemment suivant qu’on les applique sur un fichier ou un répertoire.
Lorsqu’un utilisateur exécute un programme, celui-ci se lance avec les droits de cet utilisateur. momo lance un script toto.sh, celui-ci aura les droits de momo, normal. Mais il arrive que l’on veuille lancer une commande spéciale – en général dévolue à root – en tant que simple utilisateur, l’exemple flagrant étant la commande passwd (sous /usr/bin/passwd) qui est une commande root, mais tout un chacun peut pourtant changer son mot de passe avec cette commande. En regardant les droits sur passwd, on s’aperçoit que ce fichier est setuidé 

 
Quand le système vérifie les droits d’acces, il vérifie si le numér UID correspond au propriétaire, sinon, il vérifie si le GID correspond au groupe et, enfin, si ce n’est toujours pas le cas, il considère que l’utilisateur qui essaie d’accéder à un fichier fait partie "du reste du monde"... Les numero UDI et GID servent également quand on souhaite que toute personne qui essayerait de créer/modifier un fichier/répertoire dans un répertoire donné le fasse d’office avec les droits fournis pour l’utilisateur (le groupe) à qui appartient le dossier "parent"...Ce sont les fameux bit SUID et SGID Pour répondre à ta question, jerv, tu peux trouver la liste des utilisateur ainsi que leur UID dans le fichier /etc/users et la liste des groupe ainsi que leur GID dans le fichier /etc/groups (les noms sont mis de tete, et je suis pris d’un horrible doute à leur sujet...mais en tout cas, ca ne doit pas etre bien loin de ca...) Dans l’un des fichiers, tu trouveras d’ailleurs les groupe dont font partie les utilisateurs
Sur les systèmes UNIX, Setuid n’a pas d’effet sur les répertoires.
Il est possible de voir si un fichier est Setuid ou en tapant la commande :

ls -l nom_du_fichier
 
lorsqu’un utilisateur lance la commande passwd, elle est lancée avec les droits du superutilisateur, ainsi l’écriture pourra se faire dans le fichier /etc/passwd et l’utilisateur aura changé son mot de passe sans être root. Sans le setuid, l’utilisateur n’aurait pas pu écrire dans le fichier /etc/passwd.
La notion de setuid n’existe pas pour les répertoires.k
 
setuid
 
Lorsqu’un utilisateur exécute un programme, celui-ci se lance avec les droits de cet utilisateur. momo lance un script toto.sh, celui-ci aura les droits de momo, normal. Mais il arrive que l’on veuille lancer une commande spéciale – en général dévolue à root – en tant que simple utilisateur, l’exemple flagrant étant la commande passwd (sous /usr/bin/passwd) qui est une commande root, mais tout un chacun peut pourtant changer son mot de passe avec cette commande. En regardant les droits sur passwd, on s’aperçoit que ce fichier est setuidé :
/home/momo# ls -l /usr/bin/passwd
- rwsr-xr-x 1 root root 59680 mai 17 2017 /usr/bin/passwd

setgid

Le principe du setgid est le même que le setuid pour un fichier, mais bien entendu au niveau des droits du groupe. Un exécutable setgidé peut donc être lancé avec les droits du groupe auquel il appartient. Par contre, le comportement change lorsqu’il s’agit d’un répertoire. Lorsqu’un répertoire est setgidé, tous les fichiers créés dans ce répertoire appartiennent au même groupe que le répertoire. Ainsi, imaginons un répertoire conteneur, plusieurs personnes – momo, totoet roro – travaillent dedans pour un même projet, il est bon de le setgider, de cette façon, les fichiers créés appartiendront tous au même groupe et non aux groupes de chaque utilisateur individuel.
chmod g+s kokoben
 

 
Mettre un fichier, et surtout un programme, en Setuid ou Setgid n’est pas anodin car cela court-circuite le système de protection. Ainsi si vous tapez chmod ug+s /bin/bash vous donnez les droits root à toute personne qui ouvre un terminal ou qui lance l’interpréteur de commande bash.
 
* récapitulons le plus simple des droits
r veut dire read et accorde le droit de lecture notation octale : 4
w veut dire write et accorde les droits d’écriture/modification notation octale : 2
x veut dire exécution pour un fichier exécutable (script ou binaire) mais accorde également les droits d’entrer dans un répertoire notation octale : 1
le o étant others (les autres) u étant utilisateur et g le groupe

 
STICKY BIT
stickybit peut s’appliquer aussi bien aux fichiers (et donc aux binaires/scripts)
Un exécutable peut être "sticky" (on dit aussi "avoir le sticky bit positionné") : cela signifie qu’il reste en mémoire même après la fin de son exécution, pour pouvoir être relancé plus rapidement. Alors qu’un exécutable peut être déclaré setuid et setgid par son propriétaire, seul l’administrateur système peut positionner le sticky bit.
Voyons maintenant l’utilisation du sticky bit. Comme je l’ai écrit plus haut, un utilisateur qui a le droit d’écrire dans un répertoire peut effacer n’importe quel fichier de ce répertoire. Ca peut être très gênant par exemple pour le répertoire /tmp, dans lequel tout le monde a généralement le droit d’écrire. Pour y remédier, on positionne le sticky bit ; ainsi, un utilisateur ne peut effacer que les fichier qui lui appartiennent.

Quand on écrit les permissions en octal, setuid, setgid et sticky bit sont représentés par une nouvelle série de 3 bits, qui se place avant les 3 autres séries : setuid=4, setgid=2, sticky=1. Ainsi, sur ma machine, le serveur de mail /usr/sbin/sendmail a les droits rwsr-sr-x (rwxr-xr-x, setuid, setgid) ; en octal, ça donne 6775.

le sticky bit sert a supprimer les droit d’effacement de fichier dans un repertoire
Ce droit (traduction bit collant) est utilisé pour manier de façon plus subtile les droits d’écriture d’un répertoire. En effet, le droit d’écriture signifie que l’on peut créer et supprimer les fichiers de ce répertoire. Le sticky bit permet de faire la différence entre les deux droits.
chmod +t fichier
Son flag est le t ou T, qui vient remplacer le droit d’exécution x des autres utilisateurs que le propriétaire et ceux appartenant au groupe du fichier, de la même façon que les droits SUID et SGID. La capitale fonctionne aussi de la même façon, elle est présente si le droit d’exécution x caché n’est pas présent.
 
Lire la documentation pour plus d’infos
 

numéro pas tout jeune mais intéressant pour débuter apache

téléchargez linux-magazine-spécial-apache

* Présentation rapide *




Haut de page
Systéme: Gnu_Linux_Debian