Správa linuxového serveru: Úvod do konfigurace Apache (pokračování)
V minulém díle byl probrán základ konfigurace virtuálních webů (virtual host). Tento díl je věnovaný konfiguraci v rámci jednotlivých virtuálních webů, včetně konfigurace přístupu k serveru prostřednictvím HTTPS.
Raději ještě jednou předesílám, že konfigurace Apache, která je zmíněna v tomto a v předchozím díle, je specifická pro distribuci Debian a distribuce na Debianu založené (např. Ubuntu). Jiné distribuce mohou mít odlišný mechanismus nastavování i umístění konfiguračních souborů. Mimo Debian nemusí být kupříkladu konfigurace Apache v /etc/apache2
, ale např. v /etc/httpd
(případ RHEL, CentOS, Fedory či Arch Linuxu). Podobně to pak bývá se spouštěcím skriptem, který bývá nazýván httpd,
a nikoliv apache2
. Mechanismy konfigurace a rozdělení konfiguračních souborů se také mohou lišit.
Konfigurační možnosti Apache v rámci jednotlivých virtuálních webů jsou velice široké. Zde doporučuji podívat se do dokumentace, kde je vše dopodrobna popsáno. V tomto článku budou představeny pouze ty nejpoužívanější a nejzásadnější volby. Jednou z nejobvyklejších oblastí v rámci konfigurace virtuálních webů je řízení přístupu. To se obvykle specifikuje na úrovni adresářů, jejichž konfigurační volby se „obalí“ do příslušného tagu, takto:
<Directory /var/www/example.com/>
Order deny,allow
Deny from 1.2.3.4
Allow from all
</Directory>
Zde je povolen přístup k webové prezentaci umístěné ve /var/www/example.com/
ze všech počítačů s výjimkou počítače 1.2.3.4
. Na prvním řádku uvnitř konfigurace daného adresáře se nachází pořadí, v jakém bude Apache řídit přístup - pořadí deny,allow
bude znamenat, že se nejprve projdou všechny volbyDeny
, a pokud jim klient nevyhoví, přejde se na volby Allow
. Pokud klient některé z voleb Deny
vyhoví, bude mu odmítnut přístup (HTTP kód 403).
Na druhém řádku je specifikováno odmítnutí klienta s IP adresou 1.2.3.4
. Na třetím řádku je pak povolen přístup odevšad. Je to právě pořadí provádění, které zajistí, že klientovi 1.2.3.4
bude odmítnut přístup. Kdyby bylo pořadí opačné, začalo by se nejprve u voleb Allow
, kde by byly všechny přístupy povoleny a na příslušné Deny
pravidlo by Apache nikdy nenatrefil. Na podobném principu lze velice jednoduše dosáhnout omezení přístupu k danému webu na pouze určité IP adresy, takto:
<Directory /var/www/example.com/>
Order allow,deny
Allow from 1.2.3.4
Allow from 4.3.2.1
Deny from all
</Directory>
V tomto případě je situace opačná, k webové prezentaci mohou přistupovat pouze počítače 1.2.3.4
a4.3.2.1
, ostatním bude přístup zamezen.
Důležitou konfigurační volbou pro konkrétní adresář je Options
, která řídí, které vlastnosti serveru budou v daném adresáři k dispozici. Nejčastěji se zde vypínají funkce jako adresářový index, což je vlastnost umožňující jednoduše procházet adresářovou strukturu, pokud chybí adresářový index (typicky index.html
či index.php
, lze ovlivnit volbou DirectoryIndex
). Vypnutí indexu provedete takto:
<Directory /var/www/example.com/>
Options -Indexes
Order allow,deny
Allow from 1.2.3.4
Allow from 4.3.2.1
Deny from all
</Directory>
V příkladu výše si povšimněte použití direktivy Options
. Minus zde vypíná volbu Indexes
. Ostatní možnosti v rámci Options
se dočtete v dokumentaci.
Často používanou volbou jsou aliasy. Prostřednictvím aliasů můžete mít na určité URL navázaný jiný adresář či jinou webovou aplikaci. Pokud chcete mít například v rámci jednoho virtuálního webu aplikaci Squirrelmail navázanou na URL /mail
, použijete alias, takto:
Alias /mail /usr/share/squirrelmail
<Directory /usr/share/squirrelmail>
Order allow,deny
Allow from all
<Files configtest.php>
order deny,allow
deny from all
allow from 127.0.0.1
</Files>
</Directory>
Dodávám, že tento příklad byl zkrácen, tzn. pokud budete instalovat na server Squirrelmail, použijte konfiguraci specifikovanou v dokumentaci (nebo výchozí konfiguraci Debianu), a nikoliv tento příklad. V tomto příkladu je vidět definice aliasu, kde URL /mail
odkazuje na webovou aplikaci uloženou v/usr/share/squirrelmail
, a také omezení přístupu k souboru configtest.php
, ke kterému je z bezpečnostních důvodů povolen přístup pouze z místní smyčky (localhost).
Primárním mechanismem pro zprostředkování SSL spojení je v případě Apache modul mod_ssl
, který je třeba nejprve aktivovat:
a2enmod ssl
/etc/init.d/apache2 restart
V Debianu je již k dispozici šablona pro virtuální web dostupný přes SSL, a sice /etc/apache2/sites-available/default-ssl
, kterou můžete po úpravě aktivovat takto:
a2ensite default-ssl
/etc/init.d/apache2 restart
Klíčem k provozování SSL je však dostupnost SSL certifikátu. Zde máte na výběr ze dvou možností. Buď si vygenerujete „self-signed“ (sám sebou podepsaný) SSL certifikát, na který vám dnešní prohlížeče zareagují velice odpudivě (viz obrázek níže) ve snaze odradit běžné uživatele od přístupu k takovému webu, nebo si necháte certifikát podepsat (či vygenerovat) od známé a prohlížeči uznávané certifikační autority. Problémem je, že takový certifikát není až na výjimky zdarma. Já osobně vím o dvou certifikačních autoritách, které vydávají certifikáty zdarma, a sice CAcert (stav podpory v prohlížečích) a StartSSL (stav podpory v prohlížečích). Pokud víte o nějaké další, určitě se o to podělte v komentářích pod článkem.
Reakce prohlížeče Google Chrome na self-signed certifikát
Pokud máte nainstalovaný balíček ssl-cert
, pak už máte nejspíše sebou podepsaný certifikát vygenerovaný a připravený k použití. V takovém případě nemusíte provádět vůbec nic, protože šablonadefault-ssl
je na tento certifikát připravena. V opačném případě nainstalujte zmíněný balíček, popřípadě si vygenerujte vlastní certifikát s vlastními hodnotami pomocí openssl
nebo make-ssl-cert
.
Máte-li k dispozici vlastní certifikát, vyplňte cestu k němu, k jeho klíči, popřípadě k dalším podstatným souborům, jak je naznačeno, do definice příslušného virtuálního webu (v tomto případě/etc/apache2/sites-available/default-ssl
):
SSLCertificateFile /cesta/k/certifikatu.pem
SSLCertificateKeyFile /cesta/ke/klici.key
Jak už bylo zmíněno v minulém díle, certifikát je specifický už z podstaty HTTPS protokolu pro danou IP adresu. Pokud chcete použít více certifikátů pro různé weby, musíte nakonfigurovat příslušné virtuální weby podle IP adres a každému virtuálnímu webu přiřadit jinou IP adresu. Pokud si říkáte, že takové řešení je nešťastné, máte pravdu. Měli byste vědět, že existuje ještě jeden mechanismus pro vytváření HTTPS spojení, a sice SNI (Server Name Indication), kde je zmíněný problém odstraněn, a pomocí kterého je možné na jedné IP adrese provozovat více webů chráněných různými certifikáty. Návod pro zprovoznění tohoto řešení naleznete v odkazech pod článkem. Problémem SNI je nutnost podpory tohoto řešení u všech klientů, tzn. na straně prohlížečů, kde sice podpora je, ale pouze v novějších verzích. V Debianu Lenny podpora pro SNI v modulu mod_ssl
chybí, je tedy nutno použít modul mod_gnutls
, který je k dispozici v balíčku libapache2-mod-gnutls
.
Tím bych tento díl ukončil. Příští díl se bude věnovat některým zajímavým modulům a jejich konfiguraci.