Správa webserveru Přednáška 4 Apache – proxy, bezpečnost, SSL

Obsah Apache jako proxy server Bezpečnost Dopředný server Zpětný server Bezpečnost Zabezpečení přístupu k publikovaným dokumentům Ověření uživatele při přístupu k serveru Oddělení serveru od Internetu Šifrování přenosu dat Princip bezpečné komunikace Šifrovací metody Certifikát a certifikační autority Čipové karty, časová razítka a časové autority SLL, Apache a SSL, mod_auth

Proxy server Proxy server je prvek, který se nachází na komunikační cestě mezi klientem a serverem, na který klient vznáší své požadavky. Proxy server umožňuje Zastupování Odkládání Protokolování

Typ proxy serveru Dopředný Zpětný Klienti vznášejí své požadavky na proxy server a ten získá odpověď od požadovaného serveru. Zpětný Požadavky klientů jsou směrovány na zpětný server, který je obsluhuje ze své vyrovnávací paměti nebo o ně požádá jiného hostitele.

Dopředný proxy server Používá se pro úsporu šířky pásma Umožňuje realizovat přístupové politiky Používání dopředného proxy server si musí každý uživatel nastavit

Zpětný proxy server Z pohledu internetu vznášejí klienti své požadavky přímo na webserver Uživatelé místního intranetu se připojují přímo k webserveru

mod_proxy ProxyRequests – aktivuje nebo deaktivuje službu proxy ProxyRemote – propojuje náš proxy server s jiným proxy serverem ProxyPass – promítá dokumentový strom webového serveru do dokumentového prostoru serveru proxy ProxyBlock – zablokování přístupu ke specifikovanému hostiteli nebo doméně NoProxy – určuje co se bude obsluhovat proxy serverem a co přímo webserverem ProxyDomain – specifikace doménového jména proxy serveru

mod_proxy CacheRoot – povoluje odkládání na disk CacheSize – velikost diskového prostoru pro case CacheGcInterval – kontroluje cache a odstraňuje expirované soubory CacheMaxExpire – definuje expiraci všech odložených dokumentů CacheLastModifiedFactor – stanovuje faktor pro výpočet expirace CacheDirLength – nastavuje počet znaků pro délku podadresářů CacheDirLevels – nastavuje počet podadresářů CacheDefaultExpire – nastavení implicitní dobu platnosti souboru, kdy není znám okamžik poslední změny soboru NoCache – specifikuje seznam hostitelů, pro která nebude prováděno cachování

Konfigurace proxy serveru Konfigurace proxy serveru pro požadované URL Konfigurace proxy serveru pro požadované URL definované regulárním výrazem ProxyRequests On <Directory proxy:*> … </Directory> ProxyRequests On <Directory ~ proxy:http://[^:/]+/.*> … </Directory>

Konfigurace proxy serveru Propojení soukromé sítě IP s Internetem Ukládání vzdálených webů do vyrovnávací paměti ProxyRequests On ProxyRequests On <Directory proxy:*> CacheRoot /www/cache CacheSize 1024 CacheMaxExpire 24 Order Deny, Allow Allow from mojesubdomena.upceuei.cz </Directory>

Konfigurace proxy serveru Omezení přístupu na základě použitého protokolu <Directory proxy:http:*> … </Directory> <Directory proxy:ftp:*> … </Directory> <Directory proxy:shttp:*> … </Directory>

Konfigurace proxy serveru Zrcadlení webového serveru <Directory proxy:*> ProxyPass /mirror/apache www.apache.org/ CacheRoot /www/cache CacheDefaultExpire 24 </Directory>

Principy bezpečné komunikace Důvěrnost informací Systém musí zabezpečit, že neautorizované subjekty nebudou mít možnost přístupu k důvěrným informacím Integrita Systém musí zabezpečit informace proti neautorizované modifikaci Neodmítnutelnost odpovědnosti Systém musí zabezpečit prevenci proti ztrátě schopnosti přesvědčit třetí nezávislou stranu o přímé odpovědnosti subjektu za odeslání, případně přijetí zprávy.

Zabezpečení přístupu Direktiva Order, Allow, Deny Pořadí zpracování direktiv Allow a Deny určuje direktiva Direktiva Limit Slouží k povolení přístupu pouze pro konkrétní metody <Directory “C:/apache/test”> Order Deny, Allow Allow from all Deny from none </Directory> <Limit GET POST> Order Deny, Allow Allow from all Deny from none </Limit>

Zabezpečení přístupu Direktiva LimitExcept Nastavuje přístup pro metody, které nejsou v direktivě uvedeny <LimitExcept PUT DELETE> Order Deny, Allow Allow from all Deny from none </LimitExcept>

Ověření uživatele Moduly modulu Modul mod_auth Mod_auth – základní autentizační modul (hesla v souboru) Mod_auth_anon – umožňuje anonymním uživatelům přistupovat do autenizovaných oblastí Mod_auth_dbm – autentizace uživatelů uložených v DBM (Linux DB) Mod_auth_db – autentizace uživatelů uložených v DB (Berkeley DB) Modul mod_auth Direktiva require – vynucuje autentifikace uživatele Require User – Nastavení konkrétního uživatele Require Group – Nastavení skupiny uživatelů Direktiva AuthType - Nastavení typu autentifikace Basic – kódování uživatelského jména a hesla pomocí 64base Digest – hashování uživatelského jména a hesla pomocí MD5

Základní pojmy Šifrovací algoritmus Šifrovací algoritmus je funkce, obvykle sestavená na nějakém matematickém základě, která provádí samotné šifrování a dešifrování dat. Šifrovací klíč Šifrovací klíč říká šifrovacímu algoritmu, jak má data šifrovat nebo dešifrovat. Klíče se podobají počítačovým heslům: jakmile informaci zašifrujete, musíte k jejímu dešifrování zadat správný klíč. Šifrovací algoritmus používá klíč při transformaci zašifrovaného textu zpět do nezašifrované podoby. Délka klíče Stejně jako hesla, i klíče mají nějakou předem určenou délku. Delší klíče jsou bezpečnější než kratší klíče, protože při použití útoku hrubou silou skýtají více kombinací. Různé šifrovací systémy umožňují použití klíčů různých délek, některé dovolují použití klíčů s proměnnou délkou. Výsledná kvalita ochrany dat spočívá ve zvolené šifrovací metodě, typem užitého algoritmu, jeho aplikací, a délkou šifrovacího klíče.

Šifrovací metody Symetrické šifrování Asymetrické šifrování K šifrování a dešifrování dat se používá pouze jeden klíč. Tento klíč proto musí znát obě strany. Asymetrické šifrování Data se zašifrují veřejným klíčem a mohou být dešifrovány pouze klíčem soukromým.

Symetrické šifrování

Asymetrické šifrování Přenos adresované, zašifrované (důvěrné), ale nepodepsané (neautorizované) zprávy.

Asymetrické šifrování Přenos adresované, zašifrované (důvěrné) a podepsané (autorizované) zprávy.

Šifrovací algoritmy se soukromým klíčem DES, 3DES - Data Encryption Standard (DES) je šifrovací algoritmus, vyvinutý v 70. letech Národním úřadem pro standardy a technologie (dnes National Institute of Standards and Technology, NIST) a firmou IBM. DES používá klíč o délce 56 bitů. RC2, RC4 - Blokové šifry původně vyvinuté Ronaldem Rivestem a uchovávané jako obchodní tajemství firmy RSA Data Security. RC5 - Bloková šifra vyvinutá Ronaldem Rivestem, publikovaná v roce 1994. RC5 umožňuje uživateli definovat délku klíče, délku bloku dat a počet šifrovacích průchodů. IDEA - International Data Encryption Algorithm (IDEA), vyvinutý Jamesem L. Massey a Xuejia Lai v Curychu, publikovaný v roce 1990. Skipjack - Algoritmus s klasifikací Tajný, vyvinutý Národní bezpečnostní agenturou (NSA).

Šifrovací algoritmy s veřejným klíčem Diffie-Hellman - Systém pro výměnu kryptografických klíčů mezi dvěma stranami. Nejedná se vlastně o šifrovací algoritmus, ale o metodu pro výměnu sdíleného privátního klíče přes veřejné komunikační kanály. RSA - Známý kryptografický systém s veřejným klíčem, vyvinutý (tehdejšími) profesory MITu Ronaldem Rivestem a Adi Shamirem a profesorem USC Leonardem Adlemanem. RSA je možno použít jednak jako šifrovací algoritmus a také jako základ pro systém digitálních podpisů. ElGamal - Algoritmus založený na exponenciální a modulární aritmetice. Podobně jako RSA algoritmus se dá použít k šifrování a digitálním podpisům. DSA - Digital Signature Algorithm, vyvinutý v NSA a převzatý NISTem jako federální standard pro zpracování informací (FIPS). Přestože algoritmus DSA může používat klíče libovolné délky, podle FIPS je možno použít pouze klíče o délce 512 a 1024 bitů.Jak vyplývá z názvu, DSA slouží pouze pro digitální podpisy, dá se však upravit i pro potřeby šifrování.

Certifikát Certifikát je zašifrovaná informace, která spojuje veřejný klíč s pravou identitou subjektu. Vydavatel certifikátu se označuje jako certifikační autorita Certifikační autorita Komerční Vydávají certifikát na základě prověření zákonných záznamů. Např.: www.verisign.com Soukromá (samo certifikační) Vydává si certifikáty sama k vlastní potřebě. Nepředpokládají se klienti, kteří by ji nevěřili.

Certifikační autority V ČR První certifikační autorita a.s. - http://www.ica.cz/home_cs/ CZ Czechia - http://www.caczechia.cz/ TrustPort - http://www.trustport.cz/ Ve světě VeriSign - http://www.verisign.com/ GeoTrust - http://www.geotrust.com/ Comodo - http://www.instantssl.com/ CACert - https://www.cacert.org/

Obsah certifikátu V základní formě V rozšířené formě veřejný klíč jméno a další údaje zajišťující nezaměnitelnost subjektů V rozšířené formě datum počátku a datum ukončení platnosti jméno certifikační autority, která certifikát vydala sériové číslo

Čipové karty Pasivní karty Aktivní karty Pasivní čipové karty obsahující podstatnou informaci (kryptografické klíče), která je zpracovávána vnější aplikací (slouží pouze pro úschovu této informace). Aktivní karty Aktivní čipové karty obsahující kromě podstatné informace (kryptografických klíčů) rovněž aplikaci, která tuto informaci využívá. Vnější aplikace tuto informaci smějí používat pouze zprostředkovaně.

Elektronický podpis v ČR V České Republice upraven zákonem o elektronickém podpisu č.227/2000 Sb. ze dne 29.6.2000. Další zákony a vyhlášky které upravují problematiku elektronického podpisu v ČR: Zákon 227/2000 Sb. o elektronickém podpisu Novela zákona o elektronickém podpisu (č. 440/2004 Sb.). Vyhláška 366/2001 Sb. Úřadu pro ochranu osobních údajů Zákon 101/2000 Sb. o ochraně osobních údajů Zákon 226/2002 Sb. upravující zákon o elektronickém podpisu

Problémy spojené s el. podpisem ověřování elektronického podpisu po delším čase od jeho vytvoření (např. poté co vyprší certifikát určený pro verifikaci tohoto podpisu) dlouhodobá archivace elektronicky podepsaných dokumentů

Bezpečná komunikace s el. podpisem Bezpečná komunikace s využitím elektronického podpisu a šifrováním zprávy symetrickou šifrou.

Časové razítka a časové autority Občas je nutné společně s digitálním podpisem přidat informaci, kdy byl dokument podepsán (různé žádosti, daňová přiznání, atd.) Je nutná nezávislé autority, která zajišťuje důvěryhodný zdroj času. Časové razítko Časové razítko (Time stamp TS) je struktura obdobná certifikátu, která svazuje kontrolní součet (hash) z dokumentu s časem. Časové razítko je elektronicky podepsáno (vydáváno) autoritou pro vydávání časových razítek ( Time Stamping Authority - TSA). Mezinárodní standardy pro oblast časových razítek: Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) - http://www.ietf.org/rfc/rfc3161.txt

Časové razítka a časové autority Časová autorita (Time Stamping Authority –TSA) Třetí strana, která podepisuje každé časové razítko privátním klíčem vyhrazeným pouze k tomuto účelu. TSA musí být bezpečným způsobem napojena a v pravidelných časových intervalech synchronizována proti nejlépe třem na sobě nezávislým zdrojům času. TSA používají mezinárodní standard Coordinated Universal Time UTC, který byl schválen již v roce 1972. Vydání časového razítka Klient vytvoří o odešle tzv. žádost o časové razítko ve standardizovaném formátu. Žádost o časové razítko je datová struktura obsahující kontrolní součet (hash) z dokumentu. TSA odesílá časové razítko, což je elektronicky podepsaná datová struktura obsahující číslo časového razítka, kontrolní součet z dokumentu, čas a název vydavatele časového razítka.

Elektronický podpis (electronic signature) Princip elektronického podpisu Nejprve je z podepisovaných dat vypočten kryptografický kontrolní součet. Z kryptografického kontrolního součtu je na základě tajného klíče vypočten elektronický podpis. Příjemce ověří, že elektronický podpis vyhovuje veřejnému klíči odesilatele. Vypočte kryptografický kontrolní součet přijatých dat a porovná jej s kryptografickým kontrolním součtem, který obdržel od odesilatele. Pokud součty odpovídají, je ověřeno, že data nebyla po odeslání klientem změněna. Elektronický podpis plní dvě základní funkce: Integrita – digitální podpis indikuje, zda nedošlo k modifikaci souboru nebo zprávy Autentizace – digitální podpis umožňuje matematicky ověřit, kdo zprávu podepsal

Secure Sockets Layer SSL vyvinula firma Netscape Commmunications pro zajištění bezpečné komunikace mezi klientem a serverem. SSL je komunikační protokol, který zajišťuje šifrování dat, autentizaci serveru,datovou integritu a autentizaci klienta pro komunikaci na bázi protokolu TCP/IP.

Verze SSL Verze 2.0 – první verze uvolněná pro používání, měla poměrně dost slabých míst a byla snadno napadnutelná Verze 3.0 - významná úprava bezpečnostních vlastností verze 2.0 TLS (Transaction Layer Security) – někdy označován jako SSL 3.1, vznikl v rámci IETF jako internetový standard pro nahrazení 3.0 Protokol TLS je založen na specifikaci protokolu SSL 3.0 publikované firmou Netscape. Rozdíly mezi TLS 1.0 a SSL 3.0 nejsou dramatické, ale jsou natolik významné, že spolu protokoly nespolupracují (ačkoliv TLS 1.0 obsahuje mechanismus pro zpětnou kompatibilitu se SSL 3.0). 

Sub-protokoly SSL SSL Handshake Protokol SSL Change Cipher Spec Protocol SSL Alert Protocol SSL Record Protocol

Handshake Protocol SSL Handshake Protocol Klient odešle verzi SSL, informace o šifrách, které používá a náhodně generovaná data Server odešle svoji verzi SSL, informace o šifrách, které používá, náhodně generovaná data a svůj certifikát Klient pomocí získaného certifikátu ověří důvěryhodnost serveru, pokud tak nelze učinit, je o tom informován uživatel a spojení je ukončeno Klient vytvoří z dat dosavadní komunikace tzv. premaster secret, zašifruje ho pomocí veřejného klíče serveru získaného z certifikátu a odešle ho serveru Server použije svůj privátní klíč k dešifrování premaster secret a vytvoří z něj master secret, ze kterého si vygeneruje klíč sezení Klient si rovněž vytvoří master secret a z něj vygeneruje klíč sezení Klient zašle zprávu serveru, že další data budou šifrována klíčem sezení a odešle zašifrované sdělení, že fáze handshake byla u něj skončena Server rovněž zašle, že další data budou šifrována klíčem sezení a odešle zašifrované potvrzení, že fáze handshake byla u skončena

SSL Handshake Protocol

Change Cipher Spec Protocol, Alert Protocol SSL Change Cipher Spec Protocol Tento protokol je používán v poslední fázi činnosti SSL Handshake protokolu. Jeho účelem je umožnit účastníkům přesun z vyčkávacího do provozního stavu. To znamená, že účastníci ukončí použití algoritmus výměny klíčů a začnou používat šifrovací a ověřovací algoritmy, které byly definovány v předchozích fázích Handshake protokolu. SSL Alert Protocol Významem tohoto protokolu je předávání informací o chybách objevujících se v průběhu celého spojení (connection). Výstrahy (alerts) jsou dvou úrovní – fatální a varovné. Pokud se objeví fatální výstraha, spojení je okamžitě ukončeno. Ostatní spojení používající stejnou cestu (session) mohou pokračovat, ale session ID bude označeno jako neplatné, takže na této cestě nebude možné navázat žádné nové spojení.

Record Protocol SSL Record Protocol Přenášená data jsou v případě protokolu SSL balena do objektu nazývaného record. Record obsahuje hlavičku a data (formát přenášených dat).

Apache a SSL Na Apache lze SSL provozovat jako: Modul -mod_ssl (www.modssl.org) Dopňek Apache-SSL (www.apache-ssl.org) Nutné použít kriptografickou knihovnu OpenSSL

mod_ssl LoadModule ssl_module modules/mod_ssl.so <IfDefine SSL> Přidání sdíleného modulu Přidání standardního protokolu pro HTTPS 443 Přidání typu MIME (.crt-certifikační soubor, .crl-seznam zrušených certifikátů) PHP je soubor php.ini LoadModule ssl_module modules/mod_ssl.so <IfDefine SSL> Listen 80 Listen 443 </IfDefine> <IfDefine SSL> AddType application/x-x509-ca-cert .crt AddType application/x-pkcs7-crl .crl </IfDefine>

mod_ssl <IfModule ssl_module> SSLPassPhraseDialog builtin Přidání standardního protokolu pro HTTPS 443 <IfModule ssl_module> SSLPassPhraseDialog builtin SSLSessionCache shmcb:C:/apache/logs/ssl_scache(512000) SSLSessionCacheTimeout 300 SSLMutex default SSL LLog “C:/apache/logs/ssl_engine_log” SSLLogLevel info </IfDefine>

mod_ssl <VirtualHost _default_:443> Implicitní nastavení SSL pro virtuální hostitele <VirtualHost _default_:443> DocumentRoot “C:/apache/htdocs” ServerName test1.upceuei.cz:443 SSLEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile “C:/apache/conf/server.crt” SSLCertificateKeyFile “C:/apache/conf/server.key” <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> </VirtualHost>

Vytvoření klíče a certifikátu Vytvoření soukromého klíče při tvorbě zadat do „Common Name” přesné jméno domény pro kterou bude certifikát platný Výsledkem jsou soubory: .rnd – soubor s náhodnými daty, podle kterých se vytvořil klíč my-server.csr – certifikát privkey.pem – soukromý klíč openssl req -config openssl.cnf -new -out my-server.csr

Vytvoření klíče a certifikátu Vytvoření serverového šifrovacího klíče Výsledkem je soubor: my-server.key – klíč kterým server šifruje komunikaci Vytvoření certifikátu Obdrží na začátku komunikace klientův Výsledkem je certifikát s platností 365 dni my-server.cert openssl rsa -in privkey.pem -out my-server.key openssl x509 -in my-server.csr -out my-server.cert -req -signkey my-server.key -days 365

Vytvoření klíče a certifikátu Vytvoření samostatného certifikátu Pro potřebu starších prohlížečů, do kterých se musí certifikát ručně stáhnout a nainstalovat. Výsledkem je certifikát my-server.crt openssl x509 -in my-server.cert -out my-server.crt -outform DER