Héberger ASP.NET Core sur Linux avec Apache

Par Shayne Boyer

À l’aide de ce guide, Découvrez comment configurer Apache en tant que serveur proxy inverse sur CentOS 7 pour rediriger le trafic HTTP vers une application Web ASP.net Core s’exécutant sur le Kestrel serveur. L’extension mod_proxy et les modules associés créent le proxy inverse du serveur.

Prérequis

  • Serveur exécutant CentOS 7 avec un compte d’utilisateur standard disposant du privilège sudo.
  • Installez le runtime .NET Core sur le serveur.
    1. Visitez la page Télécharger .net Core.
    2. Sélectionnez la dernière version non préliminaire de .NET Core.
    3. Téléchargez le dernier Runtime non Preview dans le tableau sous exécuter des applications-Runtime.
    4. Sélectionnez le lien des instructions du gestionnaire de package Linux et suivez les instructions CentOS.
  • Une application ASP.NET Core existante.

À tout moment après la mise à niveau de l’infrastructure partagée, redémarrez le ASP.NET Core les applications hébergées par le serveur.

Publier et copier sur l’application

Configurez l’application pour un déploiement dépendant du framework.

Si l’application est exécutée localement et n’est pas configurée pour établir des connexions sécurisées (HTTPS), adoptez l’une des approches suivantes :

  • Configurez l’application pour gérer les connexions locales sécurisées. Pour plus d’informations, consultez la section Configuration HTTPS.
  • Supprimez https://localhost:5001 (le cas échéant) de la propriété applicationUrl dans le fichier Properties/launchSettings.json.

Exécutez dotnet publish à partir de l’environnement de développement pour empaqueter une application dans un répertoire (par exemple, bin/Release/<moniker_framework_target>/publish) exécutable sur le serveur :

dotnet publish --configuration Release

L’application peut également être publiée en tant que déploiement autonome si vous préférez ne pas gérer le runtime .NET Core sur le serveur.

Copiez l’application ASP.NET Core sur le serveur à l’aide d’un outil qui s’intègre au flux de travail de l’organisation (par exemple, SCP ou SFTP). Il est courant de placer les applications web sous le répertoire var (par exemple, var/www/helloapp).

Notes

Dans un scénario de déploiement en production, un workflow d’intégration continue effectue le travail de publication de l’application et de copie des composants sur le serveur.

Configurer un serveur proxy

Un proxy inverse est une configuration courante pour traiter les applications web dynamiques. Le proxy inverse met fin à la requête HTTP et la transfère à l’application ASP.NET.

Un serveur proxy transfère les demandes des clients à un autre serveur au lieu de traiter les demandes lui-même. Un proxy inverse transfère à une destination fixe, en général pour le compte de clients arbitraires. Dans ce guide, Apache est configuré en tant que proxy inverse exécuté sur le serveur qui sert Kestrel l’application ASP.net core.

Étant donné que les demandes sont transférées par le proxy inverse, utilisez l' intergiciel d’en-têtes transmis à partir du package Microsoft. AspNetCore. HttpOverrides . Le middleware met à jour le Request.Scheme, à l’aide de l’en-tête X-Forwarded-Proto, afin que les URI de redirection et d’autres stratégies de sécurité fonctionnent correctement.

Tout composant qui dépend du schéma, tel que l’authentification, la génération de lien, les redirections et la géolocalisation, doit être placé après l’appel du middleware des en-têtes transférés.

L’intergiciel (middleware) d’en-têtes transférés doit s’exécuter avant tout autre intergiciel. Cet ordre permet au middleware qui repose sur les informations des en-têtes transférés d’utiliser les valeurs d’en-tête pour le traitement. Pour exécuter l’intergiciel (middleware) d’en-têtes transférés après les diagnostics et l’intergiciel (middleware) de gestion des erreurs, consultez ordre des intergiciels en-têtes transférés.

Appelez la UseForwardedHeaders méthode en haut de Startup.Configure avant d’appeler un autre intergiciel. Configurez le middleware pour transférer les en-têtes X-Forwarded-For et X-Forwarded-Proto :

// using Microsoft.AspNetCore.HttpOverrides;

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

app.UseAuthentication();

Si aucune option ForwardedHeadersOptions n’est spécifiée au middleware, les en-têtes par défaut à transférer sont None.

Les proxies s’exécutant sur des adresses de bouclage ( 127.0.0.0/8, [::1] ), y compris l’adresse localhost standard (127.0.0.1), sont approuvés par défaut. Si d’autres proxys ou réseaux approuvés au sein de l’organisation gèrent les requêtes entre Internet et le serveur web, ajoutez-les à la liste des KnownProxies ou des KnownNetworks avec ForwardedHeadersOptions. L’exemple suivant ajoute un serveur proxy approuvé avec l’adresse IP 10.0.0.100 au middleware des en-têtes transférés KnownProxies dans Startup.ConfigureServices :

// using System.Net;

services.Configure<ForwardedHeadersOptions>(options =>
{
    options.KnownProxies.Add(IPAddress.Parse("10.0.0.100"));
});

Pour plus d’informations, consultez Configurer ASP.NET Core pour l’utilisation de serveurs proxy et d’équilibreurs de charge.

Installer Apache

Mettez à jour les packages CentOS vers leur dernière version stable :

sudo yum update -y

Installez le serveur web Apache sur CentOS avec une seule commande yum :

sudo yum -y install httpd mod_ssl

Exemple de sortie après exécution de la commande :

Downloading packages:
httpd-2.4.6-40.el7.centos.4.x86_64.rpm               | 2.7 MB  00:00:01
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : httpd-2.4.6-40.el7.centos.4.x86_64      1/1 
Verifying  : httpd-2.4.6-40.el7.centos.4.x86_64      1/1 

Installed:
httpd.x86_64 0:2.4.6-40.el7.centos.4

Complete!

Notes

Dans cet exemple, la sortie correspond à httpd.86_64, car la version de CentOS 7 est en 64 bits. Pour vérifier où Apache est installé, exécutez whereis httpd à partir d’une invite de commandes.

Configurer Apache

Les fichiers de configuration pour Apache se trouvent dans le répertoire /etc/httpd/conf.d/. Les fichiers avec l’extension .conf sont traités par ordre alphabétique en plus des fichiers de configuration des modules dans /etc/httpd/conf.modules.d/, qui contient tous les fichiers de configuration nécessaires au chargement des modules.

Créez un fichier de configuration nommé helloapp.conf, pour l’application :

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
</VirtualHost>

<VirtualHost *:80>
    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:5000/
    ProxyPassReverse / http://127.0.0.1:5000/
    ServerName www.example.com
    ServerAlias *.example.com
    ErrorLog ${APACHE_LOG_DIR}helloapp-error.log
    CustomLog ${APACHE_LOG_DIR}helloapp-access.log common
</VirtualHost>

Le bloc VirtualHost peut apparaître plusieurs fois, dans un ou plusieurs fichiers sur un serveur. Dans le fichier de configuration précédent, Apache accepte le trafic public sur le port 80. Le domaine www.example.com est pris en charge, et l’alias *.example.com aboutit au même site web. Pour plus d’informations, consultez prise en charge des hôtes virtuels basés sur le nom. Les requêtes sont transmises par proxy à la racine vers le port 5000 du serveur sur 127.0.0.1. Pour la communication bidirectionnelle, ProxyPass et ProxyPassReverse sont requis. Pour modifier Kestrel l’adresse IP/le port de, voir Kestrel : configuration du point de terminaison.

Le bloc VirtualHost peut apparaître plusieurs fois, dans un ou plusieurs fichiers sur un serveur. Dans le fichier de configuration précédent, Apache accepte le trafic public sur le port 80. Le domaine www.example.com est pris en charge, et l’alias *.example.com aboutit au même site web. Pour plus d’informations, consultez prise en charge des hôtes virtuels basés sur le nom. Les requêtes sont transmises par proxy à la racine vers le port 5000 du serveur sur 127.0.0.1. Pour la communication bidirectionnelle, ProxyPass et ProxyPassReverse sont requis. Pour modifier Kestrel l’adresse IP/le port de, voir Kestrel : configuration du point de terminaison.

Avertissement

La spécification d’une directive ServerName incorrecte dans le bloc VirtualHost expose votre application à des failles de sécurité. Une liaison générique de sous-domaine (par exemple, *.example.com) ne présente pas ce risque de sécurité si vous contrôlez le domaine parent en entier (par opposition à *.com, qui est vulnérable). Pour plus d’informations, consultez la section rfc7230-5,4.

Vous pouvez configurer la journalisation par VirtualHost à l’aide des directives ErrorLog et CustomLog. ErrorLog est l’emplacement où le serveur journalise les erreurs, tandis que CustomLog définit le nom de fichier et le format du fichier journal. Dans ce cas, c’est l’endroit où les informations des requêtes sont journalisées. Il y a une ligne pour chaque requête.

Enregistrez le fichier et testez la configuration. Si tout réussit, la réponse doit être Syntax [OK].

sudo service httpd configtest

Redémarrez Apache :

sudo systemctl restart httpd
sudo systemctl enable httpd

Surveiller l’application

Apache est maintenant configuré pour transférer les demandes adressées à http://localhost:80 l’application ASP.net Core s’exécutant Kestrel sur http://127.0.0.1:5000 . Toutefois, Apache n’est pas configuré pour gérer le Kestrel processus. Utilisez systemd pour créer un fichier de service afin de démarrer et surveiller l’application web sous-jacente. systemd est un système d’initialisation qui fournit de nombreuses et puissantes fonctionnalités pour le démarrage, l’arrêt et la gestion des processus.

Créer le fichier de service

Créez le fichier de définition de service :

sudo nano /etc/systemd/system/kestrel-helloapp.service

Exemple de fichier de service pour l’application :

[Unit]
Description=Example .NET Web API App running on CentOS 7

[Service]
WorkingDirectory=/var/www/helloapp
ExecStart=/usr/local/bin/dotnet /var/www/helloapp/helloapp.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dotnet-example
User=apache
Environment=ASPNETCORE_ENVIRONMENT=Production 

[Install]
WantedBy=multi-user.target

Dans l’exemple précédent, l’utilisateur qui gère le service est spécifié par l' User option. L’utilisateur ( apache ) doit exister et avoir la propriété correcte des fichiers de l’application.

Utilisez TimeoutStopSec pour configurer la durée d’attente de l’arrêt de l’application après la réception du signal d’interruption initial. Si l’application ne s’arrête pas pendant cette période, le signal SIGKILL est émis pour mettre fin à l’application. Indiquez la valeur en secondes sans unité (par exemple, 150), une valeur d’intervalle de temps (par exemple, 2min 30s) ou infinity pour désactiver le délai d’attente. TimeoutStopSec prend la valeur par défaut de DefaultTimeoutStopSec dans le fichier de configuration du gestionnaire (systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d). Le délai d’expiration par défaut pour la plupart des distributions est de 90 secondes.

# The default value is 90 seconds for most distributions.
TimeoutStopSec=90

Certaines valeurs (par exemple, les chaînes de connexion SQL) doivent être placées dans une séquence d’échappement afin que les fournisseurs de configuration puissent lire les variables d’environnement. Utilisez la commande suivante pour générer une valeur correctement placée dans une séquence d’échappement en vue de son utilisation dans le fichier de configuration :

systemd-escape "<value-to-escape>"

Les séparateurs : (signe deux-points) ne sont pas pris en charge dans les noms de variables d’environnement. Utilisez un double trait de soulignement (__) à la place d’un signe deux-points. Le fournisseur de configuration de variables d’environnement convertit les doubles traits de soulignement en signes deux-points quand les variables d’environnement sont lues dans la configuration. Dans l’exemple suivant, la clé de chaîne de connexion ConnectionStrings:DefaultConnection est définie dans le fichier de définition de service en tant que ConnectionStrings__DefaultConnection :

Les séparateurs : (signe deux-points) ne sont pas pris en charge dans les noms de variables d’environnement. Utilisez un double trait de soulignement (__) à la place d’un signe deux-points. Le fournisseur de configuration de variables d’environnement convertit les doubles traits de soulignement en signes deux-points quand les variables d’environnement sont lues dans la configuration. Dans l’exemple suivant, la clé de chaîne de connexion ConnectionStrings:DefaultConnection est définie dans le fichier de définition de service en tant que ConnectionStrings__DefaultConnection :

Environment=ConnectionStrings__DefaultConnection={Connection String}

Enregistrez le fichier et activez le service :

sudo systemctl enable kestrel-helloapp.service

Démarrez le service et vérifiez qu’il s’exécute :

sudo systemctl start kestrel-helloapp.service
sudo systemctl status kestrel-helloapp.service

◝ kestrel-helloapp.service - Example .NET Web API App running on CentOS 7
    Loaded: loaded (/etc/systemd/system/kestrel-helloapp.service; enabled)
    Active: active (running) since Thu 2016-10-18 04:09:35 NZDT; 35s ago
Main PID: 9021 (dotnet)
    CGroup: /system.slice/kestrel-helloapp.service
            └─9021 /usr/local/bin/dotnet /var/www/helloapp/helloapp.dll

Avec le proxy inverse configuré et Kestrel géré par le biais de SystemD, l’application Web est entièrement configurée et accessible à partir d’un navigateur sur l’ordinateur local à l’adresse http://localhost . En examinant les en-têtes de réponse, l’en-tête de serveur indique que l’application ASP.net Core est traitée par Kestrel :

HTTP/1.1 200 OK
Date: Tue, 11 Oct 2016 16:22:23 GMT
Server: Kestrel
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked

Afficher les journaux d’activité

Étant donné que l’application Web utilisant Kestrel est gérée à l’aide de SystemD, les événements et les processus sont enregistrés dans un journal centralisé. Cependant, ce journal comprend les entrées de tous les services et processus gérés par systemd. Pour afficher les éléments propres à kestrel-helloapp.service, utilisez la commande suivante :

sudo journalctl -fu kestrel-helloapp.service

Pour le filtrage du temps, spécifiez les options appropriées dans la commande. Par exemple, utilisez --since today pour filtrer en fonction du jour actuel ou --until 1 hour ago pour voir les entrées de l’heure précédente. Pour plus d’informations, consultez la page man pour journalctl.

sudo journalctl -fu kestrel-helloapp.service --since "2016-10-18" --until "2016-10-18 04:00"

Protection des données

La pile de protection des données ASP.net Core est utilisée par plusieurs ASP.net Core intergiciels, y compris l’intergiciel (middleware) d’authentification (par exemple, cookie intergiciel) et les protections CSRF (cross-site request falsification). Même si les API de protection des données ne sont pas appelées par le code de l’utilisateur, la protection des données doit être configurée pour créer un magasin de clés de chiffrement persistantes. Si la protection des données n’est pas configurée, les clés sont conservées en mémoire et ignorées au redémarrage de l’application.

Si le Key Ring est stocké en mémoire, au redémarrage de l’application :

  • Tous les cookie jetons d’authentification de base sont invalidés.
  • Les utilisateurs doivent se reconnecter pour envoyer leur prochaine demande.
  • toutes les données protégées par le Key Ring ne peuvent plus être déchiffrées. Cela peut inclure des jetons CSRF et des ASP.NET Core les de la MVC cookie .

Pour configurer la protection des données de façon à conserver et chiffrer le porte-clés (Key Ring), consultez :

Sécuriser l’application

Configurer le pare-feu

Firewalld est un démon dynamique pour gérer le pare-feu avec prise en charge des zones réseau. Les ports et le filtrage des paquets peuvent toujours être gérés par iptables. Firewalld doit être installé par défaut. Vous pouvez utiliser yum pour installer le package ou vérifier qu’il est installé.

sudo yum install firewalld -y

Utilisez firewalld pour ouvrir seulement les ports nécessaires à l’application. Dans ce cas, les ports 80 et 443 sont utilisés. Les commandes suivantes définissent l’ouverture des ports 80 et 443 de façon permanente :

sudo firewall-cmd --add-port=80/tcp --permanent
sudo firewall-cmd --add-port=443/tcp --permanent

Rechargez les paramètres du pare-feu. Vérifiez les services et les ports disponibles dans la zone par défaut. Vous voyez les options disponibles en examinant le résultat de firewall-cmd -h.

sudo firewall-cmd --reload
sudo firewall-cmd --list-all
public (default, active)
interfaces: eth0
sources: 
services: dhcpv6-client
ports: 443/tcp 80/tcp
masquerade: no
forward-ports: 
icmp-blocks: 
rich rules: 

Configuration HTTPS

Configurer l’application pour les connexions locales sécurisées (HTTPS)

La commande dotnet run utilise le fichier Properties/launchSettings.json de l’application, qui configure l’application pour l’écoute sur les URL fournies par la propriété applicationUrl (par exemple https://localhost:5001;http://localhost:5000).

Configurez l’application pour utiliser un certificat en développement pour la commande dotnet run ou l’environnement de développement (F5 ou Ctrl+F5 dans Visual Studio Code) en adoptant l’une de ces approches :

Configurer le proxy inverse pour les connexions clientes sécurisées (HTTPS)

Avertissement

La configuration de la sécurité de cette section est une configuration générale à utiliser comme point de départ pour une personnalisation plus poussée. Nous ne pouvons pas assurer la prise en charge des outils tiers, des serveurs et des systèmes d’exploitation. Utilisez la configuration de cette section à vos propres risques. Pour plus d’informations, accédez aux ressources suivantes :

Pour configurer Apache pour HTTPS, vous utilisez le module mod_ssl. Le module mod_ssl a été installé parallèlement au module httpd. S’il n’a pas été installé, utilisez yum pour l’ajouter à la configuration.

sudo yum install mod_ssl

Pour mettre en œuvre HTTPS, installez le module mod_rewrite afin de permettre la réécriture d’URL :

sudo yum install mod_rewrite

Modifiez le fichier HelloApp. conf pour activer la communication sécurisée sur le port 443.

L’exemple suivant ne configure pas le serveur de façon à rediriger les demandes non sécurisées. Nous vous recommandons d’utiliser l’intergiciel (middleware) de redirection HTTPs. Pour plus d’informations, consultez Appliquer le protocole HTTPs en ASP.NET Core.

Notes

Pour les environnements de développement où la configuration du serveur gère la redirection sécurisée au lieu de l’intergiciel (middleware) de redirection HTTPs, nous vous recommandons d’utiliser des redirections temporaires (302) plutôt que des redirections permanentes (301). La mise en cache des liens peut provoquer un comportement instable dans les environnements de développement.

L’ajout d’un Strict-Transport-Security en-tête (HSTS) garantit que toutes les demandes ultérieures effectuées par le client sont sur HTTPS. Pour obtenir des conseils sur la définition de l' Strict-Transport-Security en-tête, consultez Appliquer le protocole HTTPs en ASP.NET Core .

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
</VirtualHost>

<VirtualHost *:443>
    Protocols             h2 http/1.1
    ProxyPreserveHost     On
    ProxyPass             / http://127.0.0.1:5000/
    ProxyPassReverse      / http://127.0.0.1:5000/
    ErrorLog              /var/log/httpd/helloapp-error.log
    CustomLog             /var/log/httpd/helloapp-access.log common
    SSLEngine             on
    SSLProtocol           all -SSLv3 -TLSv1 -TLSv1.1
    SSLHonorCipherOrder   off
    SSLCompression        off
    SSLSessionTickets     on
    SSLUseStapling        off
    SSLCertificateFile    /etc/pki/tls/certs/localhost.crt
    SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
    SSLCipherSuite        ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
</VirtualHost>

Notes

Cet exemple utilise un certificat généré localement. SSLCertificateFile doit être le fichier de certificat principal pour le nom de domaine. SSLCertificateKeyFile doit être le fichier de clé généré quand la demande de signature de certificat est créée. SSLCertificateChainFile doit être le fichier de certificat intermédiaire (le cas échéant) qui a été fourni par l’autorité de certification.

Apache HTTP Server version 2.4.43 ou ultérieure est requis pour pouvoir utiliser un serveur Web TLS 1,3 avec OpenSSL 1.1.1.

Notes

L’exemple précédent désactive l’agrafage du protocole OCSP (Online Certificate Status Protocol). Pour plus d’informations et des conseils sur l’activation du protocole OCSP, voir agrafage OCSP (documentation Apache).

Enregistrez le fichier et testez la configuration :

sudo service httpd configtest

Redémarrez Apache :

sudo systemctl restart httpd

Autres suggestions pour Apache

Redémarrer des applications avec des mises à jour de Framework partagé

Après la mise à niveau de l’infrastructure partagée sur le serveur, redémarrez le ASP.NET Core les applications hébergées par le serveur.

En-têtes supplémentaires

Pour vous protéger contre les attaques malveillantes, il existe quelques en-têtes qui doivent être modifiés ou ajoutés. Vérifiez que le module mod_headers est installé :

sudo yum install mod_headers

Sécuriser Apache contre les attaques par détournement de clic

Le détournement de clic, également appelé UI redress attack, est une attaque malveillante qui amène le visiteur d’un site web à cliquer sur un lien ou un bouton sur une page différente de celle qu’il est en train de visiter. Utilisez X-FRAME-OPTIONS pour sécuriser le site.

Pour atténuer les attaques par détournement de clic :

  1. Modifiez le fichier httpd.conf :

    sudo nano /etc/httpd/conf/httpd.conf
    

    Ajoutez la ligne Header append X-FRAME-OPTIONS "SAMEORIGIN".

  2. Enregistrez le fichier .

  3. Redémarrez Apache.

Détection de type MIME

L’en-tête X-Content-Type-Options empêche Internet Explorer d’effectuer une détection de données MIME (détermination du Content-Type d’un fichier à partir de son contenu). Si le serveur définit l’en-tête Content-Type sur text/html et que l’option nosniff est définie, Internet Explorer restitue le contenu en tant que text/html, quel que soit le contenu du fichier.

Modifiez le fichier httpd.conf :

sudo nano /etc/httpd/conf/httpd.conf

Ajoutez la ligne Header set X-Content-Type-Options "nosniff". Enregistrez le fichier . Redémarrez Apache.

Équilibrage de la charge.

Cet exemple montre comment installer et configurer Apache sur CentOS 7 et Kestrel sur la même machine d’instance. Pour ne pas avoir un point de défaillance unique ; l’utilisation de mod_proxy_balancer et la modification de VirtualHost permettent de gérer plusieurs instances des applications Web derrière le serveur proxy Apache.

sudo yum install mod_proxy_balancer

Dans le fichier de configuration illustré ci-dessous, une instance supplémentaire de helloapp est configurée pour s’exécuter sur le port 5001. La section Proxy est définie avec une configuration d’équilibreur qui comprend deux membres pour équilibrer la charge selon la méthode byrequests.

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
</VirtualHost>

<VirtualHost *:80>
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
</VirtualHost>

<VirtualHost *:443>
    ProxyPass / balancer://mycluster/ 

    ProxyPassReverse / http://127.0.0.1:5000/
    ProxyPassReverse / http://127.0.0.1:5001/

    <Proxy balancer://mycluster>
        BalancerMember http://127.0.0.1:5000
        BalancerMember http://127.0.0.1:5001 
        ProxySet lbmethod=byrequests
    </Proxy>

    <Location />
        SetHandler balancer
    </Location>
    ErrorLog /var/log/httpd/helloapp-error.log
    CustomLog /var/log/httpd/helloapp-access.log common
    SSLEngine on
    SSLProtocol all -SSLv2
    SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:!RC4+RSA:+HIGH:+MEDIUM:!LOW:!RC4
    SSLCertificateFile /etc/pki/tls/certs/localhost.crt
    SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
</VirtualHost>

Limites du débit

Vous pouvez utiliser mod_ratelimit, qui est inclus dans le module httpd, pour limiter la bande passante des clients :

sudo nano /etc/httpd/conf.d/ratelimit.conf

L’exemple de fichier limite la bande passante à 600 Ko/s sous l’emplacement racine :

<IfModule mod_ratelimit.c>
    <Location />
        SetOutputFilter RATE_LIMIT
        SetEnv rate-limit 600
    </Location>
</IfModule>

Longs champs d'en-tête de demande

Les paramètres par défaut du serveur proxy limitent généralement les champs d’en-tête de demande à 8 190 octets. Une application peut nécessiter des champs plus longs que la valeur par défaut (par exemple, les applications qui utilisent Azure Active Directory). Si des champs plus longs sont requis, la directive LimitRequestFieldSize du serveur proxy doit être ajustée. La valeur à appliquer dépend du scénario. Pour plus d'informations, voir la documentation du serveur.

Avertissement

N’augmentez pas la valeur par défaut de LimitRequestFieldSize à moins que ce ne soit nécessaire. Son augmentation augmente le risque de dépassement de mémoire tampon (dépassement de capacité) et d’attaques par déni de service (DoS) par des utilisateurs malveillants.

Ressources supplémentaires