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.

Úvod

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.

Konfigurace v rámci virtuálních webů

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.

Options

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.

Aliasy

Č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).

Konfigurace SSL/HTTPS

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

Reakce prohlížeče Google Chrome na self-signed certifikát

Generování self-signed certifikátu

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.

Použití vlastního certifikátu

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

Omezení HTTPS a možnost jeho řešení pomocí SNI

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.