Proxy servery

David Šumský, xsumsky@fi.muni.cz


Obsah

1. Co je to aplikační brána (proxy)
1.1 Proxy server
1.2 HTTP proxy cache
1.3 Jak cachování pracuje
1.4 HTTP hlavičky
1.4.1 Hlavička "čerstvost"
1.4.2 Hlavička "validátor"
1.4.3 Co většinou nefunguje
1.5 Příklad odpovědi serveru

2. Proxy servery a další ...
2.1 Squid
2.2 Privoxy
2.3 Junkbuster
2.4 TIS Firewall Toolkit
2.5 Socks5

3. Proxy server Squid (Red Hat Linux)
3.1 Instalace
3.2 Konfigurace serveru
3.2.1 Základní volby
3.2.2 Přístupová práva (ACLs)
3.2.3 Autentizace
3.2.4 Komunikace mezi servery
3.3 Zpracování logů


1. Co je to aplikační brána (proxy)

Aplikační brána (nebo také proxy) je typ firewallu, který pracuje na úrovni aplikační vrstvy. Poskytuje nám prostředky pro řízení a monitorování síťového provozu aplikačních služeb jako jsou http, ftp a další. Výhodou oproti klasickým firewallům je, že autentizace probíhá podle uživatelů, a ne podle IP adres, nevýhodou nutná úprava aplikací běžících za firewallem.


1.1 Proxy server

Aplikační brána se jeví z pohledu klientské aplikace jako server a z pohledu cílového serveru, jehož služby chce klient využívat, jako klient. Mezi klientem a cílovým (zdrojovým) serverem je vytvořeno virtuální spojení, které vytváří, řídí a kontroluje proxy server. Podstatnou výhodou některých proxy serverů je, že požadována data klientem po serveru si uloží do vyrovnávací paměti (do cache) pro případ pozdějšího výskytu podobného požadavku (tzv. cachovací proxy servery).


1.2 HTTP proxy cache

Webová cache se řadí mezi webový server a klienta nebo více klientů a snaží se sledovat jejich požadavky na HTML stránky, obrázky a jiné soubory (dále jen objekty) a příchozí data pak ukládat... Důvodem tohoto řešení je zvýšení odezvy na další příchozí požadavky, neboť můžou být vyřízeny prostřednictvím cache (je blíže klientovi) a ne samotným zdrojovým serverem, a snížení síťového provozu, neboť každý objekt se po serveru žádá a přenáší jen jednou.

Webovou cache lze implementovat na úrovni webového prohlížeče nebo právě zmiňovaného proxy serveru, což umožňuje odbavovat najednou více klientů.


1.3 Jak cachování pracuje

Cachování objektů lze ovlivnit definicí příslušných hlaviček HTTP protokolu (verze 1.0 a 1.1) nebo konfigurací cachovacího systému, jako je např. proxy server. Zpracování HTTP požadavku proxy serverem se ve stručnosti řídí následujícími pravidly:

  1. Pokud je součástí objektu hlavička "čerstvost" říkající objekt neukládat, pak se do cache ukládat nebude.
  2. Pokud součástí objektu není hlavička "validátor" , pak se většinou neukládá.
  3. Pokud má objekt co do činění s autentizací nebo se zabezpečenou komunikací, pak se určitě neukládá.
  4. Objekt je považován za "čerstvý", pokud platí podmínky:
  5. V opačném případě objekt považujeme za "starý" a je nutné požádat zdrojový server o ověření platnosti objektu ve vyrovnávací paměti.


1.4 HTTP hlavičky

Podpora cachování objektů je zahrnuta do HTTP protokolu od verze 1.0 ve formě hlaviček, které specifikují "čerstvost" a "platnost" objektu. Jejich detailní popis lze nalézt v RFC1945 a RFC2068.


1.4.1 Hlavička "čerstvost"


1.4.2 Hlavička "validátor"


1.4.3 Co většinou nefunguje


1.5 Příklad odpovědi serveru

     HTTP/1.1 200 OK
     Date: Thu, 03 Apr 2003 17:29:01 GMT
     Server: Apache/1.3.23 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.7 OpenSSL/0.9.6b
     Cache-Control: max-age=3600, must-revalidate
     Expires: Fri, 04 Apr 2003 17:29:01 GMT
     ETag: "7c00c-b4a-3d10a97a"-0
     Last-Modified: Wed, 19 Jun 2002 15:55:38 GMT
     Content-Type: text/html; charset=us-ascii
 


2. Proxy servery a další ...

2.1 Squid

Squid je velice výkonný cachovací proxy server s podporou pro HTTP, FTP, GOPHER a jiné protokoly.
Podporuje SSL, komplexní řízení přístupových práv, podrobné logování zpráv a běží na většině dnes známých operačních systémech postavených na bázi UNIXu.

Aktuální stabilní verze 2.5 je k dispozici na této stránce (docela rychle se vyvíjí) nebo na FTP.


2.2 Privoxy

Privoxy neboli Privacy Enhancing Proxy je HTTP proxy server, který spravuje cookies, kontroluje obsah webových stránek, odstraňuje z nich reklamy a různé bannery a potlačuje tvorbu tzv. vyskakovacích oken (pop-ups). Není cachovacím proxy serverem. Privoxy je založen na projektu Junkbuster (viz níže).

Návod k použití na Linuxu (RedHat):

Aktuální verze 3.0.0 je ke stažení zde.


2.3 Junkbuster

Junkbuster je další z proxy serverů blokující v HTTP komunikaci reklamní banery a neautorizované cookies ("Bust the junk out of your web browsing").

Aktuální verze 2.0.2 je ke stažení zde.


2.4 TIS Firewall Toolkit

TIS Firewall Toolkit (TIS FWTK, Trusted Information Systems Internet Firewall Toolkit) je komplexní firewallové řešení pro zabezpečení sítě.

Součástí jsou:

Pokyny ke stažení naleznete zde.


2.5 Socks5

Socks5 je proxy server filtrující protokoly FTP, telnet a jiné, není klasickou HTTP proxy.


3. Proxy server Squid (RedHat Linux)

Squid je sice výkonným proxy serverem, ale pro dosažení uspokojivých výsledků vyžaduje opravdu kvalitní hardware, zejména pak rychlý pevný disk a dostatečnou pamětovou kapacitu.
Jinak konfigurace squidu je umístěna v souboru /etc/squid.conf (nebo v adresáři /etc/squid/) a cachované objekty si většinou ukládá do adresáře /var/spool/squid.
Kromě nastavení serveru je ještě nutné nastavit klientské aplikace (webové prohlížeče apod.).


3.1 Instalace

Pokud máme k dispozici RPM balíček, stačí rpm -Uvh "jméno balíčku".
Pro kompilaci ze zdrojáků vystačíme s:

  • ./configure
  • make
  • make install

Užitečné volby skriptu configure:
  • --prefix - instalační adresář
  • --enamble-gnuregex - GNU regulární výrazy
  • --enable-async-io - pro zvýšení výkonu
  • a další ...


3.2 Konfigurace serveru

Veškerá konfigurace proxy serveru se odehrává v souboru squid.conf (sice v adresáři /etc/squid/ je souborů více, podstatný ale je hlavně squid.conf). Implicitní konfigurák squid.conf je velice rozsáhlý a při běžném použití vystačíme s pouhým zlomkem voleb v něm uvedených.


3.2.1 Základní volby

  • Základní volbou je určení portu, na kterém má proxy server poslouchat HTTP požadavky klientů. Jedná se o volbu http_port a typicky je nastavena na port 8080.
  • Volba cache_dir říká, kde ukládat obsah cache a kolik dat ukládat.
  • Volba cache_mgr obsahuje emailovou adresu administrátora cache.
  • Volby cache_effective_user a cache_effective_group nastavují jméno uživatele a skupiny, s jejichž oprávněním server poběží (přece to nespustíme s rootovskými právy, že).
  • Pro přístup k veřejným FTP serverům potřebujeme anonymního uživatele a jako heslo většinou platnou email adresu. Volbou ftp_user uvedeme právě tuto adresu.
  • Dalšími volbami specifikujeme parametry jakou jsou velikost použité RAM paměti pro cache (cache_mem), umístění logovacího souboru pro cache (cache_log), různé timeouty atd. atd.
  • Pro podrobný popis všech (ne)potřebných voleb doporučuji referenční příručku squidu dostupnou na internetové stránce squid.visolve.com nebo přímo soubor squid.conf obsahující jejich detailní komentáře.


3.2.2 Přístupová práva (ACLs)

Pro pokročilejší řízení přístupu k proxy serveru se používají tzv. Access Control Listy. Jde o velice flexibilní metodu, jak omezovat přístup uživatelů, ale zároveň je to jedna z naročnějších částí konfigurace!

  • Běžnou praxí je, že si nejdříve nadefinujeme ACL listy a těm pak zakážeme nebo povolíme přístup. To se provádí volbou acl a přístup se kontroluje volbou http_access.
        acl lab.fi.muni.cz src 10.0.0.0/255.255.255.0  <--  ACLs
        acl all src 0.0.0.0/0.0.0.0
    
        http_acces allow lab.fi.muni.cz  <--  povolí
        http_acces deny all  <-- zakáže
    

  • Volba acl má svůj typ:
    • src pro zdrojovou IP adresu klienta
    • dst pro cílovou IP adresu serveru
    • srcdomain a dstdomain pro zdrojovou a cílovou doménu
    • Dokonce lze specifikovat ACL listy na základě časového údaje, typ time, nebo použitého webového prohlížeče klienta, typ browser.
          acl agaue-alpha src 10.0.20.1
          acl morning time 06:00-11:00
          http_access agaue-alpha morning  <--  povolí přístup v dopoledních hodinách
      
  • Zpracování ACL listů probíhá shora dolů a zastaví se při první shodě s pravidlem.
  • Pokud při definici http_access pravidel zapomeneme na zamezení přístupu, pak při celkové neshodě je přístup povolen! Je proto vhodné na konec všech pravidel uvést ještě pravidlo http_access deny all :-).


3.2.3 Autentizace

  • Identita uživatelů se ověřuje externím autentizačním programem (*_auth) vybraným volbou authenticate_program. Autentizovat lze proti LDAPu, Sambě, PAMu, NCSA ...

  • ACL listy určíme, koho autentizovat
        acl foo proxy_auth username  <-- ověřovat uživatele username
        acl foo proxy_auth REQUIRE  <-- ověřovat všechny uživatele
        http_access allow foo  
    


3.2.4 Komunikace mezi servery

Pro zvýšení efektivity cachování lze proxy server nastavit tak, že pokud nenajde požadovaný objekt ve své cachi, nebude hned kontaktovat zdrojový server objektu, ale pokusí se jej nejdříve najít na jiných (sousedních) serverech. Komunikace mezi servery probíhá protokolem ICP (RFC2186, RFC2187).

  • Volba cache_peer slouží k uvedení sousední proxy cache.
        cache_peer cache.myparent.example parent 3128 3130
    


3.3 Zpracování logů

Logovací soubory squidu obsahují často velice cenné informace, z nichž lze např. vyčíst, k čemu se na netu přistupuje, co se v cachi ukládá, zda-li nastaly nějaké chyby při činnosti serveru, spotřeba diskové a paměťové kapacity apod.

Squid je založen na těchto logovacích souborech:

  • access.log obsahuje všechny příchozí požadavky klientů
  • cache.log obsahuje chybové a ladící zprávy
  • store.log udržuje seznam objektů udržovaných a odstraněných z cache
Aby život s logy byl jednodušší, existují různě užitečné nástroje pro jejich převod do čitelnější podoby.
Perlovský skript calamaris např. slouží k podrobné analýze obsahu souboru access.log a k vygenerování přehledných statistik do html souboru, jeho základní použití je:
    calamaris.pl < access.log > stats.html
Další nástroje: squidclients, squidtimes, pwebstats ...