HTTP (Hypertext Transfer Protocol) je internetový protokol určený pro výměnu hypertextových dokumentů ve formátu HTML. Používá obvykle port TCP/80. Společně s elektronickou poštou je HTTP nejvíce používaným protokolem, který se zasloužil o obrovský rozmach internetu v posledních letech.

V současné době je používán i pro přenos dalších informací. Pomocí rozšíření MIME umí přenášet jakýkoli soubor, používá se společně s formátem XML pro tzv. webové služby (spouštění vzdálených aplikací) a pomocí aplikačních bran zpřístupňuje i další protokoly, jako je např. FTP nebo SMTP.

HTTP používá jako některé další aplikace tzv. jednotný lokátor prostředků (URL, Uniform Resource Locator), který specifikuje jednoznačné umístění nějakého zdroje v Internetu.

Samotný protokol HTTP neumožňuje šifrování ani zabezpečení integrity dat. Pro zabezpečení HTTP se často používá TLS spojení nad TCP. Toto použití je označováno jako HTTPS.

Dotazovací metody HTTP:

Verze 0.9

• byla velmivvprimitivní
• umožňovalavjen prostý přenos dat ze serveru ke klientovi bez dalšíchvinformací o jejich obsahu
• klient podle přípon souborů odhadoval o jaký typ dat se jedná - což bylo postačující pokud se přenášely převážně textové dokumenty
• jakmile se začaly hromadně přenášet i jiné typy dat (obrazové, zvukové) nastaly problémy:
  • špatná identifikace typu přenášených dat
  • klient neznal objem přenášených dat (neznalost objemu stahovaných dat způsobí, že klient musí číst, dokud server neukončí spojení - což zdržuje)
  • problematická efektivita protokolu (absence mechanizmus zjištění poslední aktualizace zdroje - klient znovu stahuje zdroj, který již má, protože neví zda má aktuální)

Verze 1.0

Definováno v dokumentu RFC 1945

Nejdůležitějším přinosem této verze je možnost doprovodit dotaz i odpověď řadou doplňujících informací. V nich je možné uvést například typ dokumentu, dobu jeho vzniku či schopnosti a požadavky klienta. Formát dotazu a odpověďi doplněn o hlavičky dle standardu MIME, které popisují typ a tributy přenášených dat a mohou také obsahovat pomocné informace nebo parametry.

Verze 1.1

Definováno v dokumentu RFC 2616

• Přináší zvýšení efektivity přenosu prostřednictvím lepší práce s vyrovnávací pamětí, serverů, proxy, cache.
• Doplňuje verzi 1.0 o podporu neanglických jazyků.
• Možnost trvalého spojení mezi klientem a serverem (předchozí verze navazovaly pro každou URI nové TCP spojení)
• Trvalé spojení umožňuje zřetězené dotazování bez čekání na odpověď. Server musí odpověděť v pořadí, ve kterém je obdržel. Spojení ukončeno zasláním dotazu s příslušnou hlavičkou.

Velmi důležitým rozšířením, které tato verze HTTP protokolu přináší, je podpora virtuální serverů. Starší verze HTTP předpokládaly, že za každou IP adresou se „schovává„ jeden fyzický webový server. Nyní server může využít hlavičky host k tomu, aby zobrazil odpovídající stránku.

Verze 2

Jedná se o novou verzi, která vyšla po dlouhých patnácti letech. Zásadní změnou je podpora multiplexování. To znamená, že souběžně může být vyřizováno více požadavků, ne pouze jedna jako v HTTP/1, což by mělo nezanedbatelně zrychlit načítání stránek. Další velkou změnou je fakt, že HTTP/2 bude přenášet data v binárním formátu. Od toho se očekává zejména nižší náchylnost k chybám. HTTP/2 také počítá s kompresí hlaviček požadavků. Důvodem je zrychlení a a snížení množství přenášených dat. Díky přístupu prohlížečů dopomůže k bezpečnějšímu webu. Ty totiž budou vyžadovat šifrování.

Rozšiřitelnost (Extensibility)

Předtím, než vyšla finální verze 1.1, mnoho webových tvůrců začalo na svých projektech používat nehotové a nestandardizované funkce z připravované verze 1.1. Konečná verze tak, v rámci kompatibility s těmito pseudo-1.1 verzemi, musela tyto nedokončené a leckdy ne zcela ideální funkcionality implementovat. (Key Differences between HTTP/1.0 and HTTP/1.1) (Překlad vlastní)

Finální verze 1.1 tak v sobě obsahuje mechanismy, které umožňují maximální rozšiřitelnost pro budoucí vývoj HTTP protokolu. (Key Differences between HTTP/1.0 and HTTP/1.1) (Překlad vlastní)

Jak jsme si již řekli, pokud HTTP implementace narazila na hlavičku, které nerozuměla, tak tuto hlavičku ignorovala

OPTIONS metoda

Klient se pomocí tohoto požadavku může dozvědět o vlastnostech a funkcionalitách serveru bez toho, aniž by musel žádat nějaký objekt na specifické URI (Key Differences between HTTP/1.0 and HTTP/1.1) (Překlad vlastní)

Hlavička Upgrade

Nová hlavička upgrade umožňuje informovat server, že klient podporuje sadu (nových) protokolů, které mohou být využity ke komunikaci mezi klientem a serverem. Server se může rozhodnout, zda změnu komunikace akceptuje. (Key Differences between HTTP/1.0 and HTTP/1.1) (Překlad vlastní) Jedná se právě o mechanismus „bezbolestné“ rozšiřitelnosti HTTP protokolu. Tato funkcionalita se nyní využívá pro komunikaci pomocí WebSocket protokolu.

Kešování (Caching)

Správa síťového připojení (Network connection management)

HTTP skoro vždy používá TCP jako transportní protokol. TCP protokol je vhodný pro dlouhotrvající připojení, nicméně původní verze HTTP protokolu používá pro každý požadavek nové TCP připojení. Většina interakcí na webu jsou krátká, a tak není možné využít plný potenciál TCP připojení.

Pro stažení multimédií na webových stránkách je tak nutné vyvolat HTTP požadavek např. pro každý obrázek a zároveň tak otevírat nové TCP připojení. Je zřejmé, že toto není ideální stav a způsobuje zbytečné latence při komunikaci se serverem. Řešením jsou perzistentní spojení a řetězení. (Key Differences between HTTP/1.0 and HTTP/1.1) (Překlad vlastní)

Hlavička připojení (The Connection header)

Perzistentní, Trvalé připojení (Persistent Connections)

I když některé implementace HTTP 1.0 využívali hlavičky Connection: Keep-Alive, taková funkcionalita nebyla standardizována a tak nebyl zajištěno požadované chování.

HTTP 1.1 počítá s tím, že klient i server bude chápat perzistentní připojení jako defaultní. Spojení pak lze ukončit pomocí zaslání hlavičky Connection: close

Řetězení umožňuje využít plného potenciálu TCP spojení tím, že klient může zaslat několik HTTP požadavků bez toho, aby musel čekat na jejich postupné zpracování. Server samozřejmě musí na tyto požadavky odpovídat v tom samém pořadí, jak požadavky byly zaslány.

Můžeme říci, že původní verze HTTP protokolu uspíšila rychlý nárůst využitých IPv4 adres. Důvodem je fakt, že HTTP nedokázalo využít možnosti DNS adresovat více doménových jmen k jedné IP adrese.

HTTP 1.0 neposílala v hlavičce žádosti parametr Host, čímž znemožnila webovému serveru jednoznačně rozpoznat, jakou stránku klient žádá.

Nemusí probíhat mezi serverem a klient, lze využít prostředníka - proxy server - který dokáže zastávat jak funkci, tak i serveru. Jedna transakce se skládá z dotazu klienta a odpovědi serveru. Klient určí URI zdroje, tím také určí protokol (většinou HTTP) a zašle v hlavičce HTTP dotazu informace o tom, co klient po serveru žádá.

Server dotaz obdrží a odpoví. Tím končí jedna ucelená transakce. Následující transakce si server nedává do souvislostí s transakcemi předchozími (zde vidíme vlastnost bezstavosti HTTP protokolu).

Dotaz klienta vypadá následovně:

METODA cesta_k_dokumentu HTTP/verze
Host: jmeno_serveru (pro HTTP 1.1 povinné pole!)

Server pak odpovídá tímto způsobem:

HTTP/verze stavkod stavtext

URI (Uniform Resource Identifier – „jednotný identifikátor zdroje“) je textový řetězec s definovanou strukturou, který slouží k přesné specifikaci zdroje informací (ve smyslu dokument nebo služba), hlavně za účelem jejich použití pomocí počítačové sítě, zejména Internetu.

URI je nejobecnější z několika příbuzných typů identifikátorů. URI může popisovat zdroj jak čistě z hlediska jeho identity (a neurčovat, kde je možno zdroj získat), tak čistě z hlediska toho, jak je možno zdroj nalézt (a nepopisovat jeho identitu), tak i obojí současně – přesnou identitu zdroje i jak je možno ho dosáhnout.

Oproti URI popisuje URL primárně způsob, jakým se lze ke zdroji dostat, naopak URN specifikuje zdroj jako takový a nesnaží se o návod k jeho dosažení. Hranice mezi těmito typy je však mírně mlhavá a zejména místo URL se často uvádí obecnější termín URI.

schéma:hierarchická část?dotaz#fragment

URI = URN + URL

URL (Uniform Resource Locator = „jednotná adresa zdroje“) je řetězec znaků s definovanou strukturou, který slouží k přesné specifikaci umístění zdrojů informací (ve smyslu dokument nebo služba) na Internetu.

URL definuje doménovou adresu serveru, umístění zdroje na serveru a protokol, kterým je možné ke zdroji přistupovat.

Jednotlivá pole v URL:

protokol://server.doménadruhéhořádu.generickádoména:port/umístěnínaserveru?formulářovádata#kotva

URN (Uniform Resource Name - „jednotný identifikátor jména“). URN používá „urn“ schéma a neřeší dostupnost identifikovaného zdroje. URN spolu s URL tvoří URI.

URN jsou součástí větší internetové informační architektury, která se skládá z jednotných identifikátorů jmen (URN), jednotný charakteristik zdroje (URC) a jednotných identifikátorů zdroje (URL). Každý z nich má specifický význam:

• URN se používají k identifikaci zdroje,
• URC pro zařazení meta-informace,
• URL pro vyhledání nebo hledání zdrojů.

<URN> ::= „urn:“ <NID> „:“ <NSS>

urn:isbn:0451450523

URN pro Poslední jednorožec (knihu z roku 1968), identifikovanou pomocí jejího čísla knihy.

Některá pole jsou nepovinná – buď nemají význam, nebo se předpokládá předdefinovaná hodnota, závislá např. na schématu (např. pro protokol HTTP je implicitní port 80), nebo na aplikaci (pro webový prohlížeč se předpokládá protokol HTTP).

HTTPS (Hypertext Transfer Protocol Secure) je protokol umožňující zabezpečenou komunikaci v počítačové síti. HTTPS využívá protokol HTTP spolu s protokolem SSL nebo TLS. HTTPS je využíván především pro komunikaci webového prohlížeče s webovým serverem. Zajišťuje autentizaci, důvěrnost přenášených dat a jejich integritu. Standardní port na straně serveru je 443 TCP.

Protokol HTTPS byl v roce 1994 vyvinut společností Netscape Communications pro webový prohlížeč Netscape Navigator.

Bezpečnost komunikace zaručuje protokol SSL anebo novější TLS.

• Pomocí asymetrické kryptografie je ověřena identita webového serveru, volitelně i klienta.
• Poté následuje dohoda na klíči pro symetrické šifrování samotné komunikace (z výkonnostních důvodů). Klíč pro symetrickou šifru je buď vybrán klientem a nebo dohodnut pomocí Diffieho-Hellmanovy výměny klíče pro dosažení dopředné bezpečnosti.

Pro SSL a TLS je zásadní infrastruktura veřejného klíče a X.509 certifikáty, díky nimž probíhá autentizace. Pro úspěšné ověření identity je nutná důvěra v zaslaný certifikát, která nejčastěji bývá zprostředkovaná některou z certifikačních autorit, jejichž certifikáty jsou v úložišti důvěryhodných certifikátů operačního systému nebo aplikace (například webového prohlížeče). Většina certifikačních autorit vystavuje certifikáty na komerční bázi (Symantec, Verisign, COMODO, Thawte a jiné), avšak existují i certifikační autority vystavující certifikáty bezplatně jako například Let's Encrypt, StartSSL a jiné. Do úložiště důvěryhodných certifikátů lze doinstalovat další certifikační autority.

Nepodaří-li se certifikát ověřit automaticky, je možné na uživatelův pokyn pokračovat bez ověření (ovšem se zvýšeným rizikem Man in the middle útoku) anebo ověření provést jiným způsobem manuálně.

SSL je standardizovaná technologie (protokol) pro zabezpečenou komunikace mezi klientem a serverem. Většinou tím myslíme situaci, ve které komunikuje webový server a prohlížeč, nicméně SSL zabezpečení se může využít pro jakoukoli komunikaci na aplikační vrstvě v abstraktním modelu OSI. SSL determinuje proměnné, které budou využity pro šifrování dat.

Ustavení SSL spojení funguje na principu asymetrické šifry, kdy každá z komunikujících stran má dvojici šifrovacích klíčů – veřejný a soukromý. Veřejný klíč je možné zveřejnit a pokud tímto klíčem kdokoliv zašifruje nějakou zprávu, je zajištěno, že ji bude moci rozšifrovat jen majitel použitého veřejného klíče svým soukromým klíčem.

- Server zašle kopii svého asymetrického veřejného klíče klientovi a hlavně certifikát serveru.

1. Klient vytváří symetrický session klíč a šifruje jej pomocí asymetrického veřejného klíče serveru
2. Server dešifruje asymetrický veřejný klíč svým privátním asymetrickým klíčem tak, aby zjistil symetrický session klíč
3. Server a klient nyní komunikují symetricky pomocí symetrického session klíče.

Protokol TLS (Transport Layer Security) a jeho předchůdce SSL jsou kryptografické protokoly, poskytující možnost zabezpečené komunikace na Internetu pro služby jako WWW, elektronická pošta, internetový fax a další datové přenosy. Mezi protokoly SSL 3.0 a TLS 1.0 jsou drobné rozdíly, ale v zásadě jsou stejné.

Každý webový klient (prohlížeč) má potřebné funkcionality, aby mohl komunikovat se serverem prostřednictvím SSL protokolu. Aby klient a server započaly komunikaci, je nutný tzv. certifikát. SSL certifikáty obsahují pár klíčů: veřejný (public) a soukromý (private). SSL certifikát též obsahuje identitu vlastníka certifikátu/serveru.

CA jsou nejčastěji komerční společnosti, které certifikují klientské žádosti a potvrzují identitu žadatele. Získané informace pak připojují k vydanému certifikátu. V dnešní době se používají různé úrovně ověření majitele domény. Od jednoduchého potvrzení odkazu v zaslaném e-mailu (tzv. ověření domény) až po detailnější autorizaci včetně telefonického ověření.

FTP je v informatice protokol pro přenos souborů mezi počítači pomocí počítačové sítě. Využívá protokol TCP z rodiny TCP/IP a může být používán nezávisle na použitém operačním systému. Využívá porty 21 a 20. Port 21 slouží k řízení a jsou jím také přenášeny příkazy FTP. Port 20 slouží k vlastnímu přenosu dat.

Protokol je interaktivní a umožňuje řízení přístupu (tzn. přihlašování login/heslo), specifikaci formátu přenášeného souboru a to buď znakově nebo binárně nebo umožňuje například výpis vzdáleného adresáře atd.

V protokolu je použit model klient-server. FTP server poskytuje data pro ostatní počítače. Klient se k serveru připojí a může provádět různé operace (výpis adresáře, změna adresáře, přenos dat atd.). Operace jsou řízeny sadou příkazů, které jsou definovány v rámci FTP protokolu, proto kdokoliv může vytvořit klienta pro jakékoliv prostředí nebo operační systém.

Samotné FTP není považováno za bezpečný a z tohoto důvodu pro něj byla definována některá bezpečnostní rozšíření. Avšak ne každý klient a server je všechny podporuje. Je tedy nutné nalézt kombinaci, která bude funkční na obou stranách. Příkladem rozšíření je tzv. FTPS neboli FTP/SSL či novější TLS.

WebDAV (Web-based Distributed Authoring and Versioning) je množina rozšíření HTTP protokolu, která poskytuje možnost kooperace a vzdálené správy souborů uložených na webovém serveru. Protokol WebDAV z webu vytváří zapisovatelné paměťové médium. Poskytuje prostředí, v němž mohou uživatelé tvořit, měnit a přesouvat dokumenty na serveru (většinou na webovém serveru). V tomto prostředí se data uživateli jeví jako standardní stromově organizovaný adresářový systém. Díky rozšíření, které zahrnuje sadu metod, hlaviček, formátů dotazů a odpovědí, jsou klienti schopni provádět následující operace:

• Vytvářet, upravovat a odstraňovat soubory a dotazovat se na jejich vlastnosti (metadata), např. autor dokumentu, datum vytvoření, atd.
• Odstraňovat, vytvářet a procházet sadou souborů, tzv. kolekcí (pod tímto názvem je možno si představit běžný adresář v souborovém systému).
• Zamykat soubory, tzn. povolovat úpravy dokumentů v určitý okamžik pouze určeným uživatelům.
• Kopírovat a přesouvat soubory v rámci jmenného prostoru serveru - namespace management.

Dotaz klienta s požadavkem na server je tvořen HTTP příkazem. Na stejném řádku je zdroj a použitá verze protokolu. Následují HTTP hlavičky Host, Content-Type a Content-Length, dále mohou být obsaženy také hlavičky rozšiřující specifikace WebDAV (např. Depth). K dotazu se v některých případech ještě přidává XML dokument, který pomáhá blíže specifikovat požadovanou akci.

PROPFIND /file HTTP/1.1Host: www.example.comContent-type: application/xml; charset="utf-8"Content-Length: xxxx<?xml version="1.0" encoding="utf-8" ?><D:propfind xmlns:D="DAV:">    <propname/></D:propfind>

SPDY je experimentální síťový protokol, který byl vyvíjen pod záštitou Googlu.Hlavním cílem protokolu byla snaha o zajištění rychlejšího načítání webových stránek pomocí úpravy funkčnosti protokolu HTTP. SPDY relace je realizována uvnitř spolehlivého transportního protokolu, například TCP a pro své fungování vyžaduje implementaci na klientské i serverové straně.

Autoři naměřili až 64% zkrácení doby potřebné k načtení stránkya při úpravě parametrů TCP až 78%. Průměr zrychlení byl 29%.

Vývojáři SPDY se zapojili do vytvoření standardu HTTP/2.0, který byl v únoru roku 2015 předložen k ratifikaci. Společnost Google oznámila ukončení podpory protokolu SPDY v roce 2016 ve prospěch nového HTTP/2.0 standardu.

SPDY přidává relaci nad vrstvou SSL, která umožňuje více multiplexovaných spojení skrze jedno TCP spojení. Syntaxe HTTP metod GET a POST zůstává nezměněna pouze se definuje nový rámec pro přenos dat. SPDY poskytuje několik povinných a nepovinných funkcionalit.

Multiplexované spojení

SPDY podporuje neomezený počet souběžných toků dat skrze jediné TCP spojení. Efektivita spojení je maximalizována, protože jsou jednotlivé dotazy posílány zároveň. Sníží se tím také počet TCP spojení k jednomu web serveru.

Priorita dotazování

S multiplexem je spojen problém priority. Při pomalém spojení může dojít k zadržení paketů, které klient nutně potřebuje. SPDY implementuje prioritu dotazů (úrovně 0 až 7), která tento problém efektivně řeší.

Komprimace hlaviček

Komprimace hlaviček je vždy zapnutá a snižuje se tím počet odeslaných dat. Hlavičky jsou vždy komprimovány pomocí komprese zlib.

Server push

Na rozdíl od HTTP, může sám server začít odesílat data. V hlavičce předá klientovi informaci, že začne odesílat data, která si klient ještě nevyžádal. Toto opatření může značně zrychlit načítání stránek, které klient ještě nenavštívil. Pokud má již klient data v paměti pak je odeslání zbytečné, rozhodnutí o odeslání dat náleží jenom serveru, jelikož protokol neposkytuje informace o datech která jsou uloženy u klienta.

Server hint

Server má možnost, místo aktivního odesílání dat, pouze informovat klienta o potřebných datech. Klient pak může rychleji zareagovat vlastním dotazem. Při pomalém spojení klient rychleji zjistí, která data potřebuje, ještě před tím než by se mu stáhl předchozí dotaz.

HTTP/2 je druhá hlavní verze protokolu HTTP, tedy základního protokolu používaného webem. Ideově vychází z experimentálního protokolu SPDY, skupině Internet Engineering Steering Group byla předložena jako standard k posouzení v prosinci 2014 a byla vydána v květnu 2015, kdy byla rovněž vydána specifikace formátu komprimace hlaviček pro HTTP/2.

Podobně jako HTTP má i FTP své stavové kódy, které mohou případně pomoci při diagnostice problémů.

| Kód | Stav | Příklad |

K FTP lze přistupovat jak pomocí webových prohlížečů, tak ve Windows pomocí Windows Explorer nebo v Mac OS X pomocí Finderu. Samozřejmě existuje i mnoho FTP klientů, např. Fillezilla (Windows) nebo Cyberduck (Mac OS X).

Adresace je možná řadou způsobů. Ne všechny ovšem fungují ve webových prohlížečích.

| Adresace | Příklad |

Začneme z aplikace Správce serveru, kde přidáme novou roli přes tlačítko „Správa“.

Na obrázku níže je vidět výchozí stav, který by ovšem pro naše potřeby nedostačoval.

• Zabezpečení → Autorizace adres URL
  Umožňuje vytvářet pravidla pro přístup k webovému obsahu (lze vázat na uživatele, skupiny uživatelů nebo hlavičky HTTP). Po příchodu na stránku si vyžádá jméno a heslo.
• Zabezpečení → Omezení podle IP adresy nebo domény
  Umožňuje správci IIS omezit nebo zcela zakázat přístup podle IP adresy nebo domény.
• Zabezpečení → Základní ověřování
  Jedná se o standardní způsob přenášení jmen a hesel. Jsou přenášena v nezašifrované podobě.
• Nástroje pro správu → Služba správyUmožňuje přihlášení a tvorbu účtů IIS uživatelů.Pro instalaci Služby správy musíme doinstalovat závislost ASP.NET 4.6. Instalátor ji provede sám a bez ní nás dále nepustí.

* Server FTP → Služba FTP
Umožňuje přenos souborů mezi klientem a serverem pomocí protokolu FTP, připojení uživatelů přes FTP klienta nebo přes webový prohlížeč, který FTP podporuje (IE).

• Server FTP → Rozšiřitelnost FTP
  Podpora funkcí jako vlastní zprostředkovatelé, uživatelé technologie ASP.NET nebo uživatelé služby IIS.

• Společné funkce protokolu HTTP → Chyby protokolu HTTPUmožňuje správu chybových stránek a rozšířit možnosti uživatele při zobrazení chybové zprávy. Využijeme ji pro tvorbu chybových stránek.
  Pokud si tuto funkcionalitu nenainstalujete, budou se u chyb zobrazovat standardní chybová hlášení HTTP podle IIS.
• Společné funkce protokolu HTTP → Procházení adresářůUmožňuje zobrazení adresářové struktury webového serveru dle automaticky generovaného seznamuvšech dostupných adresářů a souborů.
• Společné funkce protokolu HTTP → Statický obsahUmožní webovému serveru publikovat formáty statických webových souborů (HTML, obrázky, CSS,…). Když na serveru obsah existuje a server dostane na něj požadavek, tak jej předá.
• Společné funkce protokolu HTTP → Výchozí dokumentDíky této možnosti můžete nakonfigurovat výchozí soubor, který server vrací automaticky vpřípadě, že uživatel neurčí soubor v adrese URL žádosti.
• Stav a diagnostika → Protokolování HTTPZápis (obvykle HTTP transakcí) do jednoho z protokolů uložených v systému souborů webového serveru. Zapisuje informace o požadavcích. Často se nazývá jako logování.
• Zabezpečení → Filtrování žádostíUmožňuje filtrovat žádosti(požadavky), které přichází na server podle pravidel nastavených správcem IIS. Slouží k zákazu/povoilení např. některých IP adres.
• Nástroje pro správu → Konzola pro správu služby IISKonzoli lze využít pro správu místního či vzdáleného webového serveru, který používá službu IIS.

Obrazovka se všemy zaškrtnutými položkami vypadá následovně:

To, že se instalace provedla, ověříme mj. také tím, že se objeví nová kartička „IIS“ ve Správci serveru.

Rozkliknutím položky IIS ve Správci Serveru si také můžeme zobrazit přehled spuštěných serverů a získat další informace.

Nástroj správy IIS můžeme spustit skrze Správce serveru a nabídku Nástroje, či příslušnou položku najít v nabídce start. Pro rychlejší přístup si ji můžeme přetáhnout mezi dlaždice.

Další možností je spustit příkaz „inetmgr.exe“.

Když si otevřeme Správce Internetové informační služby po jeho instalaci, objevíme přednastavený web s názvem „Default Web Site“. Ten je umístěn na naší doméně, pokud je server k nějaké přiřazen (tedy například http://cuni.cz). Stejně tak je dostupný přes adresu serveru (například 192.168.1.1, včetně ipv6 adresy) a přímo ze serveru je možné se ke stránce připojit také přes speciálně vyhrazenou lokální adresu (127.0.0.1, ::1, localhost).

Na obrázku výše je vidět přehled všech možných nastavení daného webu. Je důležité vědět, že věci změněné zde jsou lokální pro konkrétní instanci (ať již webu či FTP, jejichž rozhraní je takřka stejné). Pokud chcete měnit položky globálně, je potřeba je nastavovat ve stromě výše a to na našem serveru (stromová struktura je k vidění v levé části okna).

Dále je velice důležité, že některé věci nelze níže ve struktuře nastavit a je potřeba pro ně jít výše na náš server - to platí například pro generování certifikátů či celkové povolení a tvorbu uživatelů IIS. Uživatele IIS také potřeba povolit u konkrétního FTP (pro přihlašování na web jsou IIS uživatelé, alespoň z vyčerpávajícího googlení, nepoužitelní).

Pokud v Autorizačních pravidlech odepřeme některé skupině uživatel či konkrétním uživatelům přístup, potom se nám v prohlížeči objeví odpovídající chybová hláška „Error 401.2“.

Protože jsme výše zakázali anonymní přístup ale nikde našemu serveru neřekli, že chceme uživatele požádat o přihůašovací údaje při jeho pokusu o přístup na web, nemohou se uživatelé nyní na web dostat. Abychom jim to umožnili, musíme v panelu „Ověřování“ povolit „Základní ověřování“.

„Anonymní přístup“ můžeme zakázat, ale proto, že jsme ho již zakázali výše, nebude mít tato položka žádný vliv.

Potom jsou při pokusu o přístup uživatelé vyzvání k vyplnění uživatelského jména a hesla a je po vyplnění správných údajů jim je umožněn přístup na web.

Server IIS nám dále umožňuje nastavit vlastní chybové hlášky pro naše webové aplikace. To znamená, že si můžeme definovat vlastní stránky pro různé situace, například budeme-li přistupovat na chybnou adresu (404) nebo nezadáme správné přihlašovací údaje (402.2).

Každou z výchozích položek můžeme upravit nebo si nadefinovat vlastní. Pro změnu chybového kódu existující hlášky je potřeba kliknout na položku „Změnit stavový kód“, neboť v okně úpravy není tato možnost zpřístupněna. Jakmile si nadefinujeme vlastní chybovou hlášku, je nutné pro to, aby začala fungovat, dále povolit zobrazování vlastních chyb přes tlačítko „Upravit nastavení funkcí“ mezi akcemi v pravé části okna a zaškrtnout položku „Vlastní chybové hlášky“.

Pokud vytváříte vlastní chybovou hlášku pro svůj web, je potřeba zadat takový stavový kód, pro který ještě neexistuje chybová hláška v IIS a zároveň ji dokáže odchytit protokol HTTP. Dále vyvolat odpovídající chybu, na kterou server zareaguje.

1. Otevřete Správce služby IIS a přejděte na web, u kterého chceme chybové stránky spravovat.

- Ukážeme si, jak vytvořit chybovou stránku pro chybu, která nastane, pokud odstraníme index.html z fyzické cesty, ze které čerpá web informace

Pokud index.html odstraníme, po načtení webové stránky se objeví chyba 403.14 s hlášením, že webový server je nakonfigurován tak, aby nezobrazoval obsah adresáře)

1. V adresáři si vytvoříme soubor (například 403.14.html) s nějakým obsahem (například: CHYBA), který chceme zobrazovat, když nastane požadovaná chyba

3. Přejdeme do IIS – v zobrazení funkcí u vybraného webu vybereme položku Chybové stránky.

1. V pravém panelu klikneme na tlačítko Přidat
2. Nastavíme stavový kód
3. V odpovědi Akce vybereme jednu z možností:

   * Vložit obsah ze statického souboru do reakcí na chybu - slouží pro statický obsah. například. html soubor, na vlastní chyby.

   * Execute URL na této stránce - slouží dynamickému obsahu, například. Soubor ASP pro vlastní chyby.

302 přesměrování- pro přesměrování klienta prohlížeče na jinou adresu URL, která obsahuje vlastní chybový soubor.

7. Potvrdíme OK ověříme funkčnost v prohlížeči v klientském rozhraní

Přidání nového webu

Pro přídání nového webu můžeme kliknout pravým tlačítkem na položku Server nebo Weby v levé části Správce Internetové informační služby, popřípadě použít akcí na pravé straně, máme-li zrovna otevřenu jednu z položek Server nebo Weby.

Nadefinujeme si libovolný název webu (mezery jsou povoleny). Jedná se jen o reprezentaci pro nás. Dále zvolíme fyzickou cestu umístění webu.

Pokud budeme náš web umisťovat mimo adresář wwwroot, který je výchozím pro náš webový server, musíme být zvláště obezřetní a skutečně se ujistit (třeba po vytvoření webu), že k němu mají uživatelé přístup. V našich testováních jsme obecně nenarazili na potřebu upravovat oprávnění přístupu, ovšem pokud není přístup funkční, je to jedna z možností, která může uživatelům bránit.

Pro anonymní přístupy se ve výchozím stavu jedná o uživatele IUSR (to lze změnit v sekci Oveřování a úpravou Anonymního přístupu (pravým tlačítkem), kde lze definovat uživatele, jež anonymní přístupy zastupuje.

Pokud se budou uživatelé přihlašovat, pak může být nezbytné zajistit, aby tito jednotlivci měli k adresáři a všem jeho souborům, které mají vidět, přístup. Můžeme pak nastavovat oprávnění uživatelů jednotlivě nebo skrze celé skupiny, jako například „Users“. Pro statické weby budeme nejčastěji potřebovat přístup pro čtení - a v našem případě zápis potřebovat nebudeme).

Pro více informací může také sekce FTP → Zajištění přístupu do nestandardních adresářů

Další věc, která stojí za zmínku, je ip adresa, skrze kterou bude web přístupný. Ovšem pro naše účely není potřeba tuto položku měnit.
Mnohem důležitejší je zvolit si Název hostitele, tedy doménové jméno, pod kterým bude náš web dostupný. K tomu potřebujeme mít nastaven záznamy DNS (Správce serveru → Nástroje → DNS): A nebo AAAA pro domény druhého řádu (cuni.cz) a CNAME pro domény 3. řádu (www.cuni.cz či test.cuni.cz). Ty lze zadefinovat i později po nastavení webu. Stejně tak můžeme snadno vazby webu upravovat (kliknutím pravým tlačítkem na konkrétní web ve stromě aplikace Správce Internetoví informační služby nebo přes Akce vpravo ve stejné aplikaci).
Neméně důležitou položkou při nastavování webu je typ, kterým určujeme, zda bude náš web dostupný přes http nebo https protokol, popřípadě oba. S tímto souvisí i port, neboť si náš web můžeme zprovoznit i na jiném než standardním http(s) portu - ovšem musíme potom dávat pozor mj. na Firewall (ať již klienta, tak serveru), zda nám spojení neblokuje.

Všechny 4 položky z konfigurace vazby v úvodním průvodci lze později upravit a našemu webu, dokonce jemu přiřadit i více DNS záznamů atp.

Náš nový web se po dokončení průvodce objeví v seznamu dostupných webů.

Pro naše účely můžeme potřebovat umístit web i mimo standardní cestu do adresáře C:\\inetpub\wwwroot. Správce Internetové informační služby toto umožňuje velmi snadno definovat během vytváření nového webu, popřípadě později změnou přístupové cesty již existujícího webu.

V průvodci si zvolíme název našeho webu a přidáme cestu podle vlastního uvážení.

Dále zadáme název hostitele podle toho, jakou DNS adresu chceme našemu webu přiřadit.

Protože pro takto zvolenou adresu musíme mít existující záznam DNS, definujeme si jej pomocí Správce DNS, není-li již vytvořen.

V případě domény druhého řádu vytvoříme novou zónu a nastavíme A (popřípadě AAAA) záznamy. Pro doménu 3. řádu přidáme pouze CNAME do již existující domény, viz. obrázek níže.

Nyní by již měl web plně běžet. Přesto se mohou objevit potíže, zejména se zamezením přístupu k obsahu.

Níže je k dispozici výčet možných příčin:

• Je možné, že pro přístup k obsahu nebude mít uživatel přístup. V takovém případě se ujistíme, že má uživatel IUSR (v případě přetrvávajících potíží také uživatel IIS_USRS) přístup pro čtení (u FTP případě i pro zápis) do daného adresáře a na požadované soubory.Pokud je pro přístup na web vyžadována autorizace a uživatel nemá k obsahu přístup, je dále možné zkontrolovat oprávnění jednotlivých uživatelů v konkrétním adresáři včetně jeho souborů.
• V adresáři může chybět výchozí soubor pro zobrazení po přístupu do konkrétního adresáře. Je možné, že jste jej chtěli vytvořit, ale ve správci souborů máte vypnuté zobrazování přípon a soubor se tak jmenuje například index.html.txt. Níže je seznam standardně podporovaných výchozích dokumentů, který si lze ovšem rozšířit.
  • default.htm
  • default.asp
  • index.htm
  • index.html
  • iisstart.htm

Možností jak se ujistit, že do adresáře uživatel skutečně přístup má, i když se stále nic nezobrazuje, je funkce výpisu obsahu adresáře (Procházení adresáře), kterou je možné povolit globálně či lokálně pro konkrétní web. Na základě procházení adresáře potom uvidíme, jestli může uživatel soubory v adresáři zobrazovat, nebo vidí alespoň prázdný seznam bez výpisu chyby. Toto nám umožní výrazně zůžit celou škálu možných potíží, která může při nastavování webového serveru nastat.

Jak již název kapitoly napovídá, je potřeba provést změny jak ve správci IIS, tak ve správci DNS.

Správce DNS

1. Nejprve je potřeba vytvořit si pro web DNS záznam. V panelu „Nástroje“ si otevřeme správce DNS a v něm záložku „Zóny dopředného vyhledávání. Pravé tlačítko – Nový záznam

1. Po vytvoření DNS záznamu, nebo do již vytvořeného záznamu je dalším krokem vytvoření nového aliasu (CNAME) s názvem www

.

Po vytvoření DNS záznamu pro web můžeme pokračovat k samotnému přidání webu.

Přidání Webu

1. Spusťte modul správce služby IIS

- V systému Windows Server 2016 na Úvodní stránce klikněte na dlaždici Správce serveru a pak klikněte na tlačítko OK. V okně Správce serveru klikněte na nabídku Nástroje a pak klikněte na možnost Správce Internetové informační služby.

1. V podokně Připojení klikněte ve stromu pravým tlačítkem na uzel Weby a pak klikněte na možnost Přidat web.
2. V dialogovém okně Přidat web zadejte do pole Název webu popisný název webu.

4. Totéž provedeme u druhého webu, který vytváříme - Analogicky vytvoříme další web (např. beta.cuni.cz)

Do fyzických adresářů webů vložíme například index.html a jeho obsah upravíme, abychom mezi weby poznali rozdíl.

1. Po vytvoření DNS záznamů, webů v ISS a přidáním index.html s nějakým obsahem ve fyzické cestě vše ověříme v prohlížeči na uživatelském rozhraní

Pokud se změna neprojevila, zkuste server restartovat

V první řadě je potřeba vytvořit html dokument, který dále nastavíme jako výchozí dokument pro náš web.

1. Ve složce, kterou jsme udali do fyzické cesty při vytváření webu si vytvoříme html dokument (například ve složce pro web alfa si vytvoříme dokument vychozi.html), do kterého napíšeme nějaký text. Dále stačí už jen dokument nastavit jako výchozí, a to následujícím způsobem:

2. V zobrazení funkcí ve Správci služby ISS dvakrát klikneme na položku Výchozí dokument

3. V podokně Akce klikněte na tlačítko Přidat

4. Do pole Název zadejte název souboru, který chcete přidat do seznamu výchozích dokumentů a pak klikněte na tlačítko OK. Název souboru bude přidán na první místo v seznamu výchozích dokumentů.

5. po nastavení Výchozího dokumentu můžeme vyzkoušet z klientského rozhraní - web bude vypadat následovně

Pozn.: Výchozí dokumenty lze nastavit jak v rámci celého webového serveru (jak je naznačeno v návodu výše), tak v rámci jednotlivých webů, které sice nastavení webového serveru dědí, ale lze jej dodatečně změnit. Postup probíhá analogicky, nicméně do nabídky „Výchozí dokument“ nepřistupujeme z nastavení serveru, ale z nastavení webu.

Pokud chceme zakázat přístup z určité IP adresy (nebo rozsahu IP adres), použijeme k tomu právě tuto funkci.

1. Nejprve si zjistíme IP adresi klientského pc v DNS ( v levém panelu správce serveru zvolíme DNS a přečteme IP adresu – budeme mu zakazovat přístup
2. Ve správci IIS zvolíme náš web a vybereme ikonku Omezení podle IP
   

3. Poté zvolíme „Přidat pravidlo odepřít“ a vyplníme IP, kterou chceme zakázat (popř. rozsah ip adres „ip - ip“, nebo vyplníme masku)

4. Do pole „Specifická adresa“ vyplníme IP adresu, které chceme odepřít přístup

5. Ověříme na dané IP adrese v prohlížeči

Pro tvorbu vlastního certifikátu, který ovšem nebude tímto způsobem uznávaný žádnou z důvěryhodných autorit, je potřeba spustit si Správce Internetové informační služby a rozkliknout si položku Server ve stromě aplikace vlevo. Objeví se nám položka „Certifikáty serveru“, na kterou klikneme.

V této sekci vybereme v pravém sloupci Akce (popřípadě pravým tlačítkem kdekoliv uvnitř) položku „Vytvořit certifikát podepsaný sám sebou…“

Certifikát si pojmenujeme a proto, že jej budeme provozovat na našem serveru pro hostitelské služby zvolíme i tuto kategorii. Nicméně pro naše účely je jedno, které úložiště vybereme - hlavní rozdíl je v tom, že na úložišti pro hostitelské služby se lépe pravuje větší množství certifikátů, viz zdroj.

Vytvořený certifikát můžeme dále použít na našem webu, ať již editací existujícího (jeho vazeb) či tvorbou nového webu.

Při tvorbě pouze navíc zvolíme typ „https“ a vybereme příslušný certifikát. Pokud název hostitele není platným DNS záznamem, nesmíme opět zapomenout i ten vytvořit.

Pokud vše proběhlo v pořádku, bude náš web zabezpečen certifikátem, ovšem webový prohlížeč bude pro přístup na web vyžadovat explicitní povolení a bude nám zobrazovat potíže s ověřením certifikátu, neboť se nejedná o autoritou potvrzený certifikát.

MIME, celým názvem Multipurpose Internet Mail Extensions - „víceúčelová rozšíření internetové pošty“. Jedná se o standard, který byl původně vyvinut pro Elektronickou poštu, která neuměla přenášet binární data.

Slouží tedy pro přenos binárních dat – většina souborů.

MIME hlavička většinou obsahuje následující informace:
MIME-Version
Content-Type
Content-Transfer-Encoding
Content-ID
Content-Description
Syntaxe Encoded-word

Například:

   From: John Doe <example@example.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
                boundary="XXXXboundary text"
        This is a multipart message in MIME format.
        --XXXXboundary text 
Content-Type: text/plain
        this is the body text
        --XXXXboundary text 
Content-Type: text/plain;
Content-Disposition: attachment;
                filename="test.txt"
        this is the attachment text
        --XXXXboundary text--

V případě IIS serveru je potřeba mít MIME types správně nastavené pokud na serveru ukládáme nějaké soubory (doc, docx, pdf) pokud nejsou správně nastavena MIME types tak server neví, jak nám daný soubor má poslat.

Na některých starších Windows serverech je možné, že nebudou nastaveny nové přpony Microsoft Office (docx,xlsx,…) a nepůjde je tedy správně stahovat. V takovém případě je potřeba je přidat.

Jestliže máme již nainstalovaný Webový server (IIS) je třeba doinstalovat protokol FTP a služby správy přes přidání následujících rolí:

* Webový server (IIS)

• Nástroje pro správu
  • Služba správy (položka, která nám umožní vytvářet a spravovat uživatele IIS)
• Server FTP
  • Služba FTP
  • Rozšiřitelnost FTP (položka, která nám opět umožní pracovat s uživateli IIS)

Před potvrzením instalaci zaškrtnout “V případě potřeby cílový server automaticky restartovat”.

Po úspěšné instalaci protokolu FTP a služeb správy je nutný restart Windows Serveru.

Před vytvořením samotného FTP serveru je třeba ověřit, jestli je správně nastavený Firewall. Ani jedno z pravidel by nemělo být zakázáno. Pokud ano, hrozí problémy s připojením k FTP serveru.

Ve Správci IIS klikneme pravým tlačítkem na Weby a zvolíme Přidat Server FTP….

Do Název serveru FTP vyplníme název našeho FTP serveru a do Fyzická cesta najedeme cestu ke složce, která bude sloužit jako kořenový adresář pro náš FTP server. Pokud jsme si ho ještě nevytvořili, tak například na C:/ vytvoříme složku FTP_ROOT. Je ale zcela na správci serveru, kde bude cílový adresář.

V okně Nastavení SSL a vazeb pouze zvolíme Bez protokolu SSL jinak nic neměníme. Pokud by jsme chtěli mít více severů FTP bylo by potřeba zaškrtnout Povolit názvy virtuálních hostitelů a vyplnit DNS názvy, které jsme si jako správci vytvořili. Bez protokolu SSL jsme zvolili proto, že SSL protokol funguje s certifikátem, který zatím nemáme vytvořený.

V dalším okně u skupiny Ověřování zaškrtneme pouze Anonymní, jelikož chceme vytvořit server pro anonymní uživatele. Ve skupině Autorizace a Povolit přístup pro zvolíme Anonymní uživatelé. A jako Oprávnění jim zvolíme Číst i Zapisovat.


Jestliže jsme postupovali správně, tak by jsme se nyní měli na klientovi úspěšně a anonymně přihlásit na FTP server. (pro lepší přehlednost jsme si ve složce vytvořili File1.txt)

=== Řízení přístupu === == Řízení přístupu skrze Active Directory účtu == Abychom mohli vyzkoušet přístup na FTP server pomocí uživatele v Active Directory, tak si ho nejdříve musíme vytvořit. V Centrum správy Active Directory přejdeme na náš server a do skupiny Users, kde v pravé části v panelu Users klikneme na Nový a Uživatel.


Vymyslíme si fiktivního uživatele a vyplníme povinné položky. Nezapomeneme uživateli přiřadit i heslo, která pak určíme jako Heslo je platné stále ve skupině Další možnosti hesla. Kdybychom to neudělali, tak se nikdy pod tímto uživatelem na server FTP nepřihlásíme, jelikož by se pořád čekalo na klasické přihlášení od uživatele.


Na našem vytvořeném FTP serveru přejdeme do nastavení Ověřování FTP, kde zakážeme Anonymní režim a naopak povolíme režim Základní ověřování. Tyto akce najdeme v pravé části v panelu Akce. Samozřejmě by šlo nechat anonymní režim, ale pro naši ukázku je to vhodnější zakázat.


Vrátíme se zpět a tentokrát přejdeme do nastavení Autorizační Pravidla FTP, kde změníme pravidlo pro Anonymní uživatele na konkrétního námi vytvořeného uživatele. Klikneme na Anonymní uživatele a v pravé části v panelu Akce klikneme na Upravit. V následujícím okně zvolíme Určené uživatelé a napíšeme jméno našeho vytvořeného uživatele. Oprávnění necháme takové jaké jsme zvolili i pro anonymní přístup.


Jestliže jsme postupovali správně, tak by jsme se nyní měli na klientovi úspěšně přihlásit pod jménem a heslem uživatele, které jsme si vytvořili v Active Directory.


== Řízení přístupu skrze IIS účtu == V panelu Připojení klikneme na náš server. Zde nejdříve přejdeme do Služba správy, kde ve skupině Přihlašovací údaje identity změníme nastavení na Přihlašovací údaje systému Windows nebo přihlašovací údaje Správce služby IIS. Nezapomeneme v pravé části v panelu Akce dát Použít.


Vrátíme se zpět a přejdeme do Uživatelé Správce služby IIS, kde v pravé části v panelu Akce klikneme na Přidat uživatele…. Následující položky vyplníme podle potřeby.


Na našem FTP serveru přejdeme do Ověření FTP, kde zakážeme Anonymní přístup i Základní ověřování. Pokud nebudeme mít označený žádný režim, tak v pravé části v panelu Akce se objeví Vlastní zprostředkovatelé…. Klikneme na odkaz a v následujícím okně zaškrtneme a potvrdíme lisManagerAuth. Přidáme tím vlastního zprostředkovatele, který nám bude kontrolovat autentizaci uživatelů IIS.


V nastavení Oprávnění správce služby IIS, které najdeme na našem FTP serveru, vložíme uživatele, kterého jsme si vytvořili. V pravé části v panelu Akce klikneme na odkaz Povolit uživatele… a v následujícím okně přepneme na Správce služby IIS. Nyní stačí vybrat našeho vytvořeného uživatele a potvrdit.


Vrátíme se zpět a přejdeme na Autorizační pravidla FTP. Zde můžeme buď nastavit povolení pro Všichni uživatelé, kde se uživatel musí stejně přihlásit se svým uživatelským heslem, nebo určit konkrétního uživatele. My si vytvoříme pravidlo pro naše vytvořeného uživatele.


V posledním kroku musíme změnit nastavení pro složku config umístěnou v C:/Windows/System32/inetsrv/. Nastavení práv se bude týkat uživatele Network Service. Network service je uživatel, který se stará o autentizaci všech síťových připojení. Inetsrv je složka, ve které je nastavení autentizace pro IIS. Po přidání práv zapisovat pro Network Service nám vyskočí chyba, která ale v ničem nebrání. Potvrdíme a vše by mělo být v pořádku.




Jestliže jsme postupovali správně, tak by jsme se nyní měli na klientovi úspěšně přihlásit pod jménem a heslem uživatele, které jsme si vytvořili v IIS.


=== Omezení === == Omezení podle IP adres == Pokud bychom chtěli jako správci odepřít přístup na náš server FTP podle IP adresy, tak postup je následující. Na našem FTP serveru v nastavení Omezení FTP podle IP adresy a domény klikneme na odkaz Přidat položku Odepřít…. Odkaz se nachází v pravé části v panelu Akce. Nyní můžeme nastavit omezení pro specifickou IP adresu či rozsah IP adres.

== Omezení počtu pokusí přihlášení == Na našem serveru najdeme nastavení Omezení počtu pokusů o přihlášení k FTP. Zde můžeme jako správci nastavit maximální počet nezdařených pokusů za dané časové období. Následek po překročení maximálních pokusů o přihlášení si můžeme nastavit buď automatické odepření podle IP adresy nebo zapisování IP adresy pouze do protokolu. Nezapomeneme v pravé části v panelu Akce dát Potvrdit naše změny.

== Izolace uživatelů == Funkce izolace uživatelů umožňuje nakonfigurovat server FTP tak, aby izoloval uživatele, což zabraňuje uživatelům v přístupu k adresářům patřícím jiným uživatelům v rámci stejného serveru FTP. Pokud se rozhodneme uživatele neizolovat, tak všichni uživatelé budou sdílet společnou strukturu adresáře. Takové rozhodnutí je vhodné například, pokud server nabízí možnost stahování sdíleného obsahu nebo kde není nevyžadována ochranu dat mezi uživateli. Izolování je vhodné, pokud by měl mít každý uživatel například svojí složku, kde by si mohl vkládat soubory, ke kterému by měl přístup pouze on.
My si vyzkoušíme izolaci, podle uživatelského jména. Na našem serveru FTP přejdeme do nastavení Izolace uživatelů serveru FTP, kde si vybereme možnost Adresář uživatelského jména ve skupině Neizolovat uživatele. Spustit uživatele v adresáři. To pro nás samozřejmě znamená, že musíme ještě vytvořit adresář v kořenovém adresáři podle uživatelského jména. Například C:/FTP_ROOT/UserIIS/. Vybrali jsme si uživatele, s kterým jsme pracovali naposledy) - UserIIS. Nezapomeneme v pravé části v panelu Akce dát Potvrdit naše změny.


Jestliže jsme postupovali správně, tak by jsme se nyní měli na klientovi úspěšně přihlásit pod jménem a heslem uživatele, které jsme si vytvořili v IIS a to do jeho osobní složky. Nyní by neměl mít přístup do kořenového adresáře. (pro lepší přehlednost jsme si v uživatelské složce vytvořili File2.txt)


=== Protokolování === Pomocí protokolování můžeme nakonfigurovat server FTP tak, že bude zaznamenávat činnosti uživatelů a činnosti serveru. Z dat protokolu můžeme řídit přístup k obsahu, zjišťovat popularitu obsahu nebo plánovat požadavky na zabezpečen. Pomocí souborů protokolu můžeme například určit, zda došlo k události zabezpečení. Data protokolu můžou poskytnout informace o zdroji útoku.
Služba IIS ve výchozím nastavení používá formát souboru protokolu W3C Extended. Formát souboru protokolu W3C Extended je obvykle upřednostňovaný. Tento formát protokolu umožňuje konfigurovat mnoho rozšířených atributů které jsou užitečné při analýze zabezpečení.
Na našem FTP serveru přejdeme do nastavení Protokolování FTP. Ve skupině Soubor protokolu můžeme vybrat kam se nám budou protokoly zapisovat a jaké pole / atributy budou použity. Změna souboru protokolu nastavíme, jak často bude soubor protokolu vytvářen a jestli bude použit místní čas pro pojmenování daného souboru. Nastavení zcela na správci FTP serveru.

=== Připojení FTP serveru k HTTP webu === K tomu, aby jsme mohli přistupovat k souborům našeho webu je zapotřebí připojit web k FTP serveru. Ve Správce IIS klikneme pravým tlačítkem na náš web a vybereme možnost Přidat publikování FTP…. Návod, kterým vytvoříme FTP server jsme si již popisovali výše.

=== Nastavení FTPS === Pro nastavení FTPS neboli FTP/SSL zabezpečení je zapotřebí mít certifikát. Jak vytvořit certifikát si popisujeme výše. Pokud certifikát máme, tak na našem serveru FTP v Nastavení SSL serveru FTP, přidat náš vytvořený certifikát, zvolit Povolit připojení SSL a potvrdit na pravé straně v panelu Akce. === Zajištění přístupu do nestandardních adresářů === Pokud se nemohou uživatelé do našeho FTP přihlásit, je možné, že nemáme správně nastavená přístupová práva. To je obzvláště pravda pro adresáře v domovském adresáři uživatele. Obecně vzato je vhodné si kromě standardních věcí jako je Firewall zkontrolovat také, zda má do adresáře přístup uživatel „NETWORK SERVICE“ a zároveň skupina (např. „Users“) či uživatel (např. „peta“), který se do ní snaží přistoupit. Nezbytný je přístup pro čtení, pokud chceme uživatelům povolit i zápis potom také přístup pro zápis.
==== Fondy aplikací ==== Fond aplikací služby ISS je izolovaný paměťový prostor, který je směrován do jednoho či více pracovních procesů uvnitř kontextu zabezpečení daného uživatele. Pracovní proces (w3wp.exe) spouští webové aplikace a obsluhuje požadavky zaslané serveru pro určitý fond aplikací. Webová aplikace s vlastním fondem aplikací nebude ovlivněna problémy s jinými aplikacemi v odděleném fondu aplikací. Jestliže používají dvě webové aplikace tentýž fond, tak na jednu stranu se snižuje nároky na paměť, ale na druhou stranu se přináší riziko havárie obou webových aplikací v případě, kdy jedna z nich kvůli špatně napsanému kódu nebo kompromitovanému serveru havaruje. Můžeme vybrat limit, jaký podíl využití CPU přidělíme jednotlivým aplikacím. Pokud někdo tento limit překročí, můžeme zastavit běh této aplikace po určitou zvolenou dobu.

Dále si můžeme například nastavit počet aplikací, které budou běžet současně. Pokud nastavíme tento počet na 0, systém bude tento počet nastavovat automaticky podle potřeby.

Je možné si nastavit .NET rozhraní, které zrovna požadujeme. (.NET Framework je prostředí potřebné pro běh aplikací a nabízí jak spouštěcí rozhraní, tak potřebné knihovny)
Jestliže jsme si vytvořili svůj vlastní fond, je zapotřebí ho přiřadit k HTTP webu či FTP serveru. Na našem FTP serveru v pravé části v panelu Akce klikneme na odkaz Základní nastavení…, kde si můžeme zvolit náš vlastní fond.
==== Více FTP na jedné IP adrese ==== I když na jednom serveru a jedné IP adrese lze velice snadno zprovoznit více webů s pomocí DNS záznamů, pro FTP není situace zdaleka tak přímočará. Ať již přistupujete na IIS FTP skrze jakékoliv doménové jméno určité IP adresy, vždy budete přesměrováni na hlavní FTP účet (nejspíše ten, který jste nastavili jako první - konkrétně ten, který se ve vazbách váže na A či AAAA záznam). Pokud chcete mít na jednom serveru více FTP účtů, pak je potřeba, aby tento hlavní učet vyžadoval autentizaci, neboť pro přesměrování na další exstující účty se využívá trik v zápisu uživatelského jména při přihlašování. Pro přihlášení na libovolný jiný než hlavní FTP server je potřeba zadat uživatelské jméno ve formě „uživatel|vazba“, tedy například „pepa|ftp.cuni.cz“. Vazba je ten záznam, který jste nastavili při tvorbě FTP účtu, popřípadě při jeho pozdější editaci, a není potřeba aby skutečně takové jméno v DNS existovalo, protože pro přístup na konkrétní FTP účet je možné přistupovat libovolným DNS jménem odkazujícím na relevatní IP adresu či přímo IP adresou. Jediné co rozhoduje o umístění FTP úložiště je právě onen doplněk za svislítkem (pajpou) v uživatelském jméně. Z této skutečnosti vyplývá, že pokud budeme potřebovat více FTP účtů na jedné IP adrese, nemůžeme na ní provozovat žádný anonymní FTP provoz. === Postup === Přidáme nový FTP server, nastavíme mu libovolný název a požadovanou cestu.

Na další stránce je velice důležité zvolit virtuálního hostitele, tj. náš jednoznačný identifikátor, který později použijeme pro přihlašování. Není nutné, aby byl součástí DNS, pokud neplánujeme na FTP přes toto DNS přistupovat, neboť je možné se na něj odkazovat kterýmkoliv doménovým jménem konkrétní IP adresy serveru.


Na další stránce již jen zaškrtneme komu chceme přihlašování povolit a jaká práva budou uživatelé či jeden uživatel mít, podobně jako výše. Je důležité zvolit si základní ověřování, neboť anonymního ověřování nelze v případě více FTP na jedné IP adrese využít.



Protože jsme v tomto případě nezvolili standardní cestu ale umístění, kam nemají naši uživatelé ani „NETWORK SERVICE“ přístup, nebude možné se zde přihlásit. Musíme tedy doplnit oprávnění do daného adresáře právě o „NETWORK SERVICE“ a uživatele, kterým chceme umožnit přihlašování (například skupinou „Users“) - nezbytný je přístup pro čtení a v závislosti na to, zda chceme uživatelům umožnit také zápis, i přístup pro zápis.

Po zadání správných přihlašovacích údajů v pořadí „vazba|uživatel“ se již budeme moct do našeho FTP dostat:
==== Zdroje ==== Sestavování a správa webových aplikací. PDF [online]. [cit. 2017-04-29]. Dostupné z: knihy.cpress.cz/?p=actions&action=download/file&value=files&id=104558 MICROSOFT. Configure FTP with IIS Manager Authentication in IIS 7. Microsoft [online]. [cit. 2017-04-29]. Dostupné z: https://www.iis.net/learn/publish/using-the-ftp-service/configure-ftp-with-iis-manager-authentication-in-iis-7 JUKKA KORPELA. FTP URLs. CS. Tut [online]. 2008 [cit. 2017-04-29]. Dostupné z: https://www.cs.tut.fi/~jkorpela/ftpurl.html WIKIMEDIA FOUNDATION. Secure Sockets Layer (SSL). Wikipedia [online]. [cit. 2017-04-29]. Dostupné z: https://cs.wikipedia.org/wiki/Secure_Sockets_Layer WIKIMEDIA FOUNDATION. .NET Framework. Wikipedia [online]. [cit. 2017-04-29]. Dostupné z: https://cs.wikipedia.org/wiki/.NET WIKIMEDIA FOUNDATION. List of FTP server return codes. Wikipedia [online]. [cit. 2017-04-29]. Dostupné z: https://en.wikipedia.org/wiki/List_of_FTP_server_return_codes MICROSOFT. The FTP status codes in IIS 7.0. Support Microsoft [online]. [cit. 2017-04-29]. Dostupné z: https://support.microsoft.com/cs-cz/help/969061/the-ftp-7-0-status-codes-in-iis-7-0 DIGICERT. What Is SSL (Secure Sockets Layer) and What Are SSL Certificates? DigiCert [online]. [cit. 2017-04-29]. Dostupné z: http://www.digicert.com/ssl.htm MICROSOFT. How to enable logging in IIS. Support Microsoft [online]. [cit. 2017-04-29]. Dostupné z: https://support.microsoft.com/cs-cz/help/313437/how-to-enable-logging-in-internet-information-services-iis