Hostování ASP.NET Core v Linuxu pomocí Apache

Shayne Boyer

V této příručce se dozvíte, jak nastavit Apache jako reverzní proxy server CentOS 7 pro přesměrování provozu HTTP do ASP.NET Core aplikace běžící na Kestrel serveru. Rozšíření mod_proxy a související moduly vytvářejí reverzní proxy server.

Požadavky

  • Server se systémem CentOS 7 se standardním uživatelským účtem s oprávněním sudo.
  • Nainstalujte na server modul runtime .NET Core.
    1. Navštivte stránku pro stažení .NET Core.
    2. Vyberte nejnovější verzi .NET Core, která není ve verzi Preview.
    3. Stáhněte si nejnovější modul runtime bez verze Preview v tabulce v části Spustit aplikace – Modul runtime.
    4. Vyberte odkaz s pokyny správce balíčků pro Linux a postupujte podle pokynů pro CentOS.
  • Existující ASP.NET Core aplikace.

Kdykoli v budoucnu po upgradu sdílené architektury restartujte ASP.NET Core aplikace hostované serverem.

Publikování a kopírování aplikace

Nakonfigurujte aplikaci pro nasazení závislé na rozhraní.

Pokud je aplikace spuštěná místně a není nakonfigurovaná pro zabezpečené připojení (HTTPS), proveďte některý z následujících přístupů:

  • Nakonfigurujte aplikaci tak, aby zvládla zabezpečená místní připojení. Další informace najdete v části Konfigurace HTTPS.
  • Odeberte https://localhost:5001 (pokud je k dispozici) applicationUrl z vlastnosti v souboru Properties/launchSettings.json.

Spusťte dotnet publish z vývojového prostředí a zabalte aplikaci do adresáře (například bin/Release/target_framework_moniker < > /publish), který se může spustit na serveru:

dotnet publish --configuration Release

Pokud nechcete udržovat modul runtime .NET Core na serveru, můžete aplikaci publikovat také jako samostatné nasazení.

Zkopírujte ASP.NET Core aplikaci na server pomocí nástroje, který se integruje do pracovního postupu organizace (například SCP, SFTP). Webové aplikace se běžně nachází v adresáři var (například var/www/helloapp).

Poznámka

V produkčním scénáři nasazení pracovní postup kontinuální integrace dělá práci publikování aplikace a kopírování prostředků na server.

Konfigurace proxy server

Reverzní proxy je běžné nastavení pro obsluhu dynamických webových aplikací. Reverzní proxy server ukončí požadavek HTTP a předá ho ASP.NET aplikaci.

Služba proxy server požadavky klientů na jiný server místo samotného plnění požadavků. Reverzní proxy server se přeposílá do pevného cíle, obvykle jménem libovolných klientů. V této příručce je Apache nakonfigurovaný jako reverzní proxy server běžící na stejném serveru, který ASP.NET Core Kestrel aplikaci.

Vzhledem k tomu, že požadavky se předá reverzním proxy serverem, použijte middleware Forwarded Headers z balíčku Microsoft.AspNetCore.HttpOverrides. Middleware aktualizuje pomocí hlavičky , aby identifikátory URI přesměrování a další zásady zabezpečení Request.Scheme X-Forwarded-Proto fungovaly správně.

Každá komponenta, která závisí na schématu, jako je ověřování, generování propojení, přesměrování a geografická poloha, musí být umístěna po vyvolání middlewaru Forwarded Headers.

Middleware předaných hlaviček by se měla spustit před jiným middlewarem. Toto řazení zajišťuje, aby middleware spoléhající se na předané informace hlaviček mohl spotřebovat hodnoty hlaviček pro zpracování. Pro spuštění předávaných middlewarových hlaviček po diagnostice a middlewaru zpracování chyb si přečtěte téma pořadí middlewaru u předaných hlaviček.

Před UseForwardedHeaders voláním jiného Startup.Configure middlewaru vyvolte metodu v horní části . Nakonfigurujte middleware tak, aby předá X-Forwarded-For X-Forwarded-Proto hlavičky a :

// using Microsoft.AspNetCore.HttpOverrides;

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

app.UseAuthentication();

Pokud je ForwardedHeadersOptions pro middleware zadaný parametr no, výchozí hlavičky, které se mají předat dál, jsou None .

Proxy servery spuštěné na adresách zpětné smyčky ( ), včetně standardní adresy místního hostitele 127.0.0.0/8, [::1] (127.0.0.1), jsou ve výchozím nastavení důvěryhodné. Pokud žádosti mezi internetem a webovým serverem zřídí jiné důvěryhodné proxy servery nebo sítě v rámci organizace, přidejte je do seznamu nebo KnownProxies KnownNetworks pomocí ForwardedHeadersOptions . Následující příklad přidá důvěryhodnou adresu proxy server IP adresu 10.0.0.100 do middlewaru předáných hlaviček v KnownProxies Startup.ConfigureServices :

// using System.Net;

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

Další informace naleznete v tématu Konfigurace ASP.NET Core pro práci s proxy servery a nástroji pro vyrovnávání zatížení.

Instalace Apache

Aktualizujte balíčky CentOS na nejnovější stabilní verze:

sudo yum update -y

Nainstalujte webový server Apache v CentOS jediným yum příkazem:

sudo yum -y install httpd mod_ssl

Ukázkový výstup po spuštění příkazu:

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!

Poznámka

V tomto příkladu se ve výstupu zobrazí httpd.86_64, protože verze CentOS 7 je 64bitová. Pokud chcete ověřit, kde je apache nainstalovaný, whereis httpd spusťte z příkazového řádku příkaz .

Konfigurace Apache

Konfigurační soubory pro Apache se nacházejí v /etc/httpd/conf.d/ adresáři . Všechny soubory s příponou .conf se zpracovávají v abecedním pořadí kromě konfiguračních souborů modulu v nástroji , který obsahuje všechny konfigurační soubory potřebné k /etc/httpd/conf.modules.d/ načtení modulů.

Vytvořte pro aplikaci konfigurační soubor s názvem helloapp.conf:

<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>

Blok VirtualHost se může zobrazit vícekrát v jednom nebo více souborech na serveru. V předchozím konfiguračním souboru Apache přijímá veřejný provoz na portu 80. Doména www.example.com se obsluhou. *.example.com Alias se překládá na stejný web. Další informace najdete v tématu Podpora virtuálních hostitelů založených na názvu. Požadavky se proxy serverem od kořenového adresáře do portu 5000 serveru ve verzi 127.0.0.1. Pro obousměrnou komunikaci jsou ProxyPass ProxyPassReverse vyžadovány a . Informace o Kestrel změně IP adresy nebo portu najdete v tématu : Konfigurace Kestrel koncového bodu.

Blok VirtualHost se může zobrazit vícekrát v jednom nebo více souborech na serveru. V předchozím konfiguračním souboru Apache přijímá veřejný provoz na portu 80. Doména www.example.com se obsluhou. *.example.com Alias se překládá na stejný web. Další informace najdete v tématu Podpora virtuálních hostitelů založených na názvu. Požadavky se proxy serverem od kořenového adresáře do portu 5000 serveru ve verzi 127.0.0.1. Pro obousměrnou komunikaci jsou ProxyPass ProxyPassReverse vyžadovány a . Informace o Kestrel změně IP adresy nebo portu najdete v tématu : Konfigurace Kestrel koncového bodu.

Upozornění

Pokud v bloku VirtualHost nezadáte správnou direktivu ServerName, zpřístupníte aplikaci ohrožením zabezpečení. Vazba se zástupnými znaky subdomény (například ) nepředstavuje toto bezpečnostní riziko, pokud řídíte celou nadřazenou doménu (na rozdíl od , která *.example.com *.com je zranitelná). Další informace najdete v dokumentu rfc7230 section-5.4.

Protokolování je možné nakonfigurovat podle VirtualHost direktiv using ErrorLog a CustomLog . ErrorLog je umístění, kam server protokoluje chyby, CustomLog a nastavuje název souboru a formát souboru protokolu. V tomto případě se do protokolu zaprotokoluje informace o požadavku. Pro každý požadavek je jeden řádek.

Uložte soubor a otestujte konfiguraci. Pokud vše projde, odpověď by měla být Syntax [OK] .

sudo service httpd configtest

Restartujte Apache:

sudo systemctl restart httpd
sudo systemctl enable httpd

Monitorování aplikace

Apache je teď nastavený tak, aby předal požadavky provedené do http://localhost:80 aplikace ASP.NET Core běžící na Kestrel adrese http://127.0.0.1:5000 . Apache ale není nastavený pro správu Kestrel tohoto procesu. Pomocí systemd a vytvoření souboru služby spusťte a monitorujte základní webovou aplikaci. systemd je inivací systém, který poskytuje mnoho výkonných funkcí pro spouštění, zastavování a správu procesů.

Vytvoření souboru služby

Vytvořte definiční soubor služby:

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

Příklad souboru služby pro aplikaci:

[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

V předchozím příkladu je uživatel, který službu spravuje, určen User parametrem . Uživatel ( ) musí existovat a mít správné vlastnictví apache souborů aplikace.

Slouží ke konfiguraci doby čekání na vypnutí aplikace po přijetí signálu TimeoutStopSec počátečního přerušení. Pokud se aplikace v tomto období nevypne, aplikace se ukončí příkazem SIGKILL. Zadejte hodnotu jako unitless seconds (například ), hodnotu časového rozsahu (například ), nebo pokud 150 chcete časový limit 2min 30s infinity zakázat. TimeoutStopSec výchozí hodnota je v konfiguračním souboru DefaultTimeoutStopSec manageru (systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d). Výchozí časový limit pro většinu distribucí je 90 sekund.

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

Některé hodnoty (například SQL připojovací řetězce) musí být uvozené, aby zprostředkovatelé konfigurace načetli proměnné prostředí. Pomocí následujícího příkazu vygeneruje správně uvozenou hodnotu pro použití v konfiguračním souboru:

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

Oddělovače : dvojtečky ( ) nejsou podporovány v názvech proměnných prostředí. Místo dvojtečky použijte dvojité __ podtržítko ( ). Zprostředkovatel konfigurace Proměnných prostředí převede dvě podtržítka na dvojtečky, když se proměnné prostředí načtou do konfigurace. V následujícím příkladu je klíč připojovacího ConnectionStrings:DefaultConnection řetězce nastavený do definiční souboru služby jako ConnectionStrings__DefaultConnection :

Oddělovače : dvojtečky ( ) nejsou podporovány v názvech proměnných prostředí. Místo dvojtečky použijte dvojité __ podtržítko ( ). Zprostředkovatel konfigurace Proměnných prostředí převede dvě podtržítka na dvojtečky, když se proměnné prostředí načtou do konfigurace. V následujícím příkladu je klíč připojovacího řetězce ConnectionStrings:DefaultConnection nastaven do souboru definice služby jako ConnectionStrings__DefaultConnection :

Environment=ConnectionStrings__DefaultConnection={Connection String}

Uložte soubor a povolte službu:

sudo systemctl enable kestrel-helloapp.service

Spusťte službu a ověřte, že je spuštěná:

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

U reverzního proxy serveru nakonfigurovaného a Kestrel spravovaného pomocí systému je webová aplikace plně nakonfigurovaná a je dostupná z prohlížeče v místním počítači v http://localhost . při kontrole hlaviček odpovědi se v hlavičce serveru označuje, že ASP.NET Core aplikace obsluhuje 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

Zobrazení protokolů

Vzhledem k tomu, že webová aplikace, která používá Kestrel je spravovaná pomocí systému, se události a procesy protokolují do centralizovaného deníku. Tento deník ale obsahuje položky pro všechny služby a procesy spravované systémem. Chcete-li zobrazit kestrel-helloapp.service položky specifické pro zobrazení, použijte následující příkaz:

sudo journalctl -fu kestrel-helloapp.service

Pro filtrování času zadejte možnosti času pomocí příkazu. Použijte například --since today k filtrování aktuálního dne nebo --until 1 hour ago k zobrazení záznamů předchozí hodiny. Další informace najdete na stránce muž pro journalctl.

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

Ochrana dat

sada ASP.NET Core Data Protection stack je používána několika ASP.NET Core middlewary, včetně middlewaru ověřování (například cookie middlewaru) a ochrany proti padělání žádostí mezi lokalitami (CSRF). I v případě, že rozhraní API ochrany dat nejsou volána uživatelským kódem, je třeba chránit data, aby bylo možné vytvořit trvalé úložiště kryptografických klíčů. Pokud ochrana dat není nakonfigurovaná, klíče se uchovávají v paměti a při restartování aplikace se zahodí.

Pokud se klíčového prstence při restartu aplikace uloží do paměti:

  • U cookie tokenů ověřování na základě jsou neověřené.
  • Uživatelé se musí znovu přihlásit na svůj další požadavek.
  • Data chráněná pomocí Key ringu už nebude možné dešifrovat. to může zahrnovat CSRF tokeny a ASP.NET Core MVC TempData cookie s.

Pokud chcete nakonfigurovat ochranu dat, aby zachovala a zašifroval klíč Ring, přečtěte si:

Zabezpečení aplikace

Konfigurace brány firewall

Brána firewall je dynamickým démonem pro správu brány firewall s podporou síťových zón. Filtrování portů a paketů je stále možné spravovat pomocí softwaru iptables. Brána firewall by měla být nainstalována ve výchozím nastavení. yum dá se použít k instalaci balíčku nebo ověření, jestli je nainstalovaný.

sudo yum install firewalld -y

Slouží firewalld k otevření pouze portů potřebných pro aplikaci. V tomto případě se používají porty 80 a 443. Následující příkazy trvale nastaví porty 80 a 443 na otevřené:

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

Znovu načtěte nastavení brány firewall. Ověřte dostupné služby a porty ve výchozí zóně. Možnosti jsou k dispozici na základě kontroly 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: 

Konfigurace HTTPS

Konfigurace místních připojení (HTTPS) aplikace pro zabezpečení

Příkaz příkazového řádku dotnet používá vlastnosti nebo launchSettings.jsaplikace v souboru, který nakonfiguruje aplikaci tak, aby naslouchala adresám URL poskytnutým applicationUrl vlastností (například https://localhost:5001;http://localhost:5000 ).

nakonfigurujte aplikaci tak, aby používala certifikát ve vývoji pro dotnet run příkazové nebo vývojové prostředí (F5 nebo Ctrl + F5 v Visual Studio Code), a to pomocí jednoho z následujících přístupů:

Konfigurace připojení klienta reverzního proxy serveru pro zabezpečení (HTTPS)

Upozornění

Konfigurace zabezpečení v této části je Obecná konfigurace, která se má použít jako výchozí bod pro další přizpůsobení. Nemůžeme poskytovat podporu pro nástroje, servery a operační systémy třetích stran. Konfiguraci v této části použijte na vlastní riziko. Další informace získáte v následujících zdrojích informací:

Pro konfiguraci Apache pro HTTPS se používá modul mod_ssl . Po instalaci modulu httpd byl také nainstalován modul mod_ssl . Pokud není nainstalovaná, použijte yum ji k přidání do konfigurace.

sudo yum install mod_ssl

Pokud chcete vynutilit protokol HTTPS, nainstalujte mod_rewrite modul, aby se povolilo přepsání adresy URL:

sudo yum install mod_rewrite

Úpravou souboru helloapp. conf povolte zabezpečenou komunikaci na portu 443.

Následující příklad neprovádí konfiguraci serveru pro přesměrování nezabezpečených požadavků. Doporučujeme použít middleware pro přesměrování protokolu HTTPS. Další informace naleznete v tématu Vynucení HTTPS v ASP.NET Core.

Poznámka

Pro vývojová prostředí, kde konfigurace serveru zpracovává zabezpečené přesměrování místo middleware pro přesměrování protokolu HTTPS, doporučujeme použít dočasné přesměrování (302) místo trvalých přesměrování (301). Ukládání odkazů do mezipaměti může způsobit nestabilní chování ve vývojových prostředích.

Přidáním Strict-Transport-Security hlavičky (HSTS) se zajistí, že všechny následné požadavky, které klient provede, budou přes protokol HTTPS. Pokyny k nastavení Strict-Transport-Security hlavičky najdete v tématu Vynucení HTTPS v 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>

Poznámka

Tento příklad používá místně generovaný certifikát. SSLCertificateFile by měl být primárním souborem certifikátu pro název domény. SSLCertificateKeyFile by měl být soubor klíče vygenerovaný při vytvoření CSR. SSLCertificateChainFile by měl být soubor zprostředkujícího certifikátu (pokud existuje), který poskytla certifikační autorita.

Aby bylo možné provozovat webový server TLS 1,3 s OpenSSL 1.1.1, je potřeba server Apache HTTP verze 2.4.43 nebo novější.

Poznámka

Předchozí příklad zakáže připojení protokolu OCSP (Online Certificate Status Protocol). Další informace a pokyny k povolení protokolu OCSP najdete v tématu připojení k protokolu OCSP (dokumentace k Apache).

Uložte soubor a otestujte konfiguraci:

sudo service httpd configtest

Restartujte Apache:

sudo systemctl restart httpd

Další návrhy Apache

Restartovat aplikace se sdílenými aktualizacemi rozhraní

po upgradu sdílené architektury na serveru restartujte aplikace ASP.NET Core hostované serverem.

Další záhlaví

Aby bylo možné zabezpečit před škodlivými útoky, je třeba upravit nebo přidat několik hlaviček. Ujistěte se, že mod_headers je modul nainstalovaný:

sudo yum install mod_headers

Zabezpečení Apache před útoky clickjacking

Clickjacking, označovaný také jako útok s opravou uživatelského rozhraní, je škodlivý útok, při kterém návštěvník webu získá odkaz nebo tlačítko na jiné stránce, než se právě navštíví. Slouží X-FRAME-OPTIONS k zabezpečení lokality.

Zmírnění útoků Clickjacking:

  1. Upravte soubor httpd. conf :

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

    Přidejte řádek Header append X-FRAME-OPTIONS "SAMEORIGIN".

  2. Soubor uložte.

  3. Restartujte Apache.

Sledování typu MIME

X-Content-Type-OptionsZáhlaví brání aplikaci Internet Explorer ve sledování MIME (určení souboru Content-Type z obsahu souboru). Pokud server nastaví Content-Type hlavičku na text/html nosniff sadu možností, Internet Explorer vykreslí obsah text/html bez ohledu na obsah souboru.

Upravte soubor httpd. conf :

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

Přidejte řádek Header set X-Content-Type-Options "nosniff". Soubor uložte. Restartujte Apache.

Vyrovnávání zatížení

Tento příklad ukazuje, jak nastavit a nakonfigurovat Apache na CentOS 7 a Kestrel na stejném počítači instance. Aby nedošlo k jednomu bodu selhání; použití mod_proxy_balancer a úpravou VirtualHost by umožňovalo spravovat více instancí webových aplikací za proxy server Apache.

sudo yum install mod_proxy_balancer

V konfiguračním souboru uvedeném níže helloapp je nastavená další instance, která se spustí na portu 5001. Oddíl proxy je nastaven s konfigurací vyrovnání se dvěma členy pro vyrovnávání zatížení 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>

Omezení přenosové rychlosti

Pomocí mod_ratelimit, který je součástí modulu httpd , může být omezena šířka pásma klientů:

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

Ukázkový soubor omezuje šířku pásma na 600 KB/s v kořenovém umístění:

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

Pole hlavičky dlouhé žádosti

Výchozí nastavení proxy serveru obvykle omezují pole hlaviček požadavku na 8 190 bajtů. aplikace může vyžadovat pole delší než výchozí (například aplikace, které používají Azure Active Directory). Pokud jsou požadována delší pole, vyžaduje direktiva LimitRequestFieldSize proxy server úpravu. Hodnota, která se má použít, závisí na scénáři. Další informace najdete v dokumentaci k vašemu serveru.

Upozornění

Nerozšiřovat výchozí hodnotu, LimitRequestFieldSize Pokud je to nutné. Zvýšení hodnoty zvyšuje riziko přetečení vyrovnávací paměti (přetečení) a útok DoS (Denial of Service) uživateli se zlými úmysly.

Další zdroje informací