Proxy server                                                                                  Nastavenie a vypnutie proxy servera tu

Server proxy alebo proxy server je server počítačovej siete, ktorý umožňuje klientom nepriame pripojenie k inému serveru. Proxy server funguje ako sprostredkovateľ medzi klientom a cieľovým serverom, prekladá požiadavky klienta a oproti cieľovému serveru vystupuje ako klient. Prijatú požiadavku potom odosiela naspäť klientovi. Môže ísť tak o špecializovaný hardvér, ako aj o softvér bežiaci na počítači.

Aplikačný proxy server je server špeciálne určený pre určitý protokol resp. aplikáciu. S jeho pomocou je možné analyzovať obsah komunikácie, prípadne ju pozmeniť (napr. odstraňovanie reklám z HTTP požiadaviek, blokovanie webových stránok podľa obsahu,...) alebo ukladať požiadavky do vyrovnávacej pamäte (cache), a tak zefektívniť komunikáciu.

Ochrana súkromia 

Pre cieľový server je klientom proxy server a nie pôvodný klient. To má za následok, že cieľový server nepozná IP adresu pôvodného klienta. Prevažne u webových proxy serverov nie je toto opatrenie stopercentné, keďže niektoré z nich pridávajú adresu klienta do upravenej požiadavky. Úpravou požiadavky však možno ešte viac zvýšiť súkromie, a to odstraňovaním cookies alebo iných informácií (napr. referrer – informácie o poslednej navštívenej stránke).

Zvýšenie výkonu komunikácie 

V prípade, že sa niektoré požiadavky klienta opakujú (napr. požiadavka na stiahnutie Wikipédie, dotazy na DNS a pod.), môže si proxy server uložiť odpoveď do vyrovnávacej pamäte a odpoveď odoslať priamo klientovi - bez toho aby predal komunikáciu až k cieľovému serveru.

Bezpečnosť 

Aplikačný proxy server môže analyzovať komunikáciu, zisťovať prítomnosť vírusov, šifrovať a dešifrovať prichádzajúce požiadavky a podobne.

Pripojenie viacerých klientov k internetu 

Preklad IP adries, tzv. NAT umožňuje oddeliť intranet od internetu (typicky s pomocou firewallu).

 

 

 

7.1 Čo je proxy server

Proxy server je špeciálny typ servera - prostredníka v komunikácii, ktorý sa umiestňuje medzi klienta a servery, s ktorými komunikuje. Proxy server sa tvári voči klientovi ako server a voči serveru ako klient. Výhodou je, že proxy server pozná požiadavku klienta a vie mu doručiť odpoveď, aj keď klient samotný nemôže alebo nevie (kvôli obmedzeniam alebo parametrom siete) priamo komunikovať so vzdialeným serverom.

Činnosť proxy servera možno opísať v niekoľkých bodoch:

  1. klient sa spojí s proxy serverom namiesto toho, aby kontaktoval vzdialený server
  2. proxy server prevezme požiadavku klienta, ktorá obsahuje adresu vzdialeného servera, s ktorým chce klient komunikovať
  3. proxy server sa stane klientom, spojí sa so vzdialeným serverom a odovzdá mu požiadavku od svojho klienta
  4. vzdialený server odpovie
  5. proxy server prevezme odpoveď od vzdialeného servera a doručí ju svojmu klientovi

Je výhodné, ak je proces nastavenia klienta pre prácu s proxy serverom pokiaľ možno jednoduchý (v praxi sa nastavuje typ proxy servera, jeho adresa a port, na ktorom pracuje). Existuje dokonca riešenie, pri ktorom sa na strane klienta nenastavuje vôbec nič a všetky požiadavky idú automaticky cez proxy server. Takéto riešenie sa volá "transparentný proxy server".

Situácia bez použitia proxy servera:

  +-------------+   požiadavka                           +--------+
  | klient      |--------------------------------------> | server |
  | (lok. sieť) |<-------------------------------------- |        |
  +-------------+                             odpoveď    +--------+
  

Situácia s použitím proxy servera:

  +-------------+ požiadavka  +--------+ požiadavka      +--------+
  | klient      |-----------> | proxy  |---------------> | server |
  | (lok. sieť) |<----------- | server |<--------------- |        |
  +-------------+   odpoveď   +--------+      odpoveď    +--------+
  

Keďže proxy server pozná klienta, od ktorého prišla požiadavka, môže riadiť prístup k informáciám. Navyše, za určitých okolností (pre isté služby) môže získanú odpoveď nejako spracovať, napríklad si ju zapamätať (cache). Ak dostane tú istú požiadavku od ďalšieho klienta, môže mu poskytnúť odpoveď oveľa rýchlejšie. Toto sa využíva najmä pri cachovaní obsahu WWW stránok.

Rozlišujeme dva druhy proxy serverov:

  1. Aplikačné proxy servery: sú navrhnuté iba pre vybrané sieťové služby, ako napr. http, https, ftp. Výhodou je, že nastavovanie klienta nie je zložité, stačí uviesť adresu proxy servera a jeho port.
  2. SOCKS proxy servery: fungujú pre ľubovoľné služby (TCP?) za predpokladu, že aplikácia podporuje tento typ proxy servera (musí byť špeciálne upravená).

Existujú najmä tieto tri dôvody, prečo nasadiť proxy server v praxi:

7.1.1 Oddelenie sietí - bezpečnosť

Lokálne siete používajú často privátne adresy (napr. 10.0.0.0/255.255.255.0), takže počítače nemôžu komunikovať priamo s Internetom. Používa sa buď preklad adries na firewalli (Network Address Translation - NAT), alebo riešenie pomocou proxy servera. Klient používa proxy server na svojej vlastnej privátnej sieti (má privátnu IP adresu) a ten komunikuje (najčastejšie pomocou iného sieťového pripojenia) s Internetom.

Výhodou použitia proxy servera z hľadiska bezpečnosti teda je:

  1. možno ho použiť na prístup k (určitým službám) Internetu aj v prípade, že klienti používajú privátne adresy (netreba použiť NAT)
  2. možno ho použiť iba na prístup k tým službám, ktoré podporuje proxy server
  3. klient sa pripája na proxy server a nie priamo na server - takže nekomunikuje priamo s vonkajšou sieťou, čím sa dosahuje vyššia bezpečnosť, lebo nemožno zneužiť prebiehajúce spojenie na útok smerujúci zo servera na klienta.

Prirodzene, riešenie má aj svoje nevýhody:

  1. možno ho použiť iba na prístup k tým službám, ktoré podporuje proxy server (toto je výhoda aj nevýhoda zároveň, podľa toho, z akého uhla sa na vec pozeráte)
  2. ak používate aplikačný proxy server, spracovanie aplikačnej vrstvy modelu OSI (bežné sieťové protokoly založené na TCP), do komunikácie vnáša isté spomalenie (proxy musí analyzovať najvrchnejšiu vrstvu modelu OSI)

Treba poznamenať, že pre niektoré siete je použitie prístupu pomocou proxy servera jedinou možnosťou prístupu na Internet. Neskôr sa dozviete, ako sa to dá využiť na riadenie prístupu.

Odporúčania:

Ak použijete proxy server, vzdialený server nekomunikuje priamo s klientom, takže nemôže proti nemu podniknúť útok, môže však zneužiť spojenie so samotným proxy serverom. Tento treba preto čo najlepšie zabezpečiť (pomocou firewallu):

  • proxy server nepotrebuje prijímať spojenia z vonkajšej siete, ale iba odpovede na už vytvorené spojenia (stavový filter v IPTABLES: ESTABLISHED).
  • proxy server sa nepotrebuje pripájať do vnútornej siete! Posiela iba odpovede na už vytvorené spojenia (stavový filter v IPTABLES: ESTABLISHED).
  • proxy server by mal počúvať iba na portoch, ktoré sú nevyhnutné pre správnu prevádzku služby. O tomto budem písať neskôr pre konkrétnu implementáciu proxy servera.

 

7.1.2 Cache pre obsah (WWW) - rýchlosť odozvy

Ako som spomenul, niektoré typy aplikačných proxy serverov (napr. HTTP proxy) môžu disponovať cache pamäťou, v ktorej určitý čas uchovávajú odpovede serverov a obsah tejto pamäte je k dispozícii pre ďalšie požiadavky. Ak proxy server nájde požadovanú odpoveď v cache, vie odpovedať klientovi rýchlejšie, ako keby musel odpoveď opäť získať. To je výhodné najmä v prípade, že pripojenie na Internet nie je veľmi rýchle, kým rýchlosť na lokálnej sieti dosahuje dnes bežne 100Mb/s.

Mohlo by sa zdať, že hlavnou výhodou je teda menší čas odozvy na požiadavku klienta, čo je aj pravda - ale iba v prípade, že sa odpoveď nachádza v cache. Jej veľkosť je totiž vždy obmedzená (okrem fyzickej pamäti sa používa aj disk). Aby sa do cache mohli ukladať údaje, musí sa z nej niečo odstrániť. Na to existuje niekoľko algoritmov, napr. odstránia sa najmenej používané údaje. Najrýchlejšiu odozvu na požiadavku dosiahnete pomocou proxy servera vtedy, ak budete napríklad v prípade HTTP proxy pristupovať na najčastejšie používané stránky.

Výhoda použitia proxy servera teda je:

  1. zmenšenie času odozvy ("vyššia rýchlosť") pre najčastejšie požiadavky (nachádzajú sa v cache)

Nevýhody:

  1. obmedzená veľkosť cache: podľa Murphyho zákonov sa môže stať, že práve vaša požiadavka sa v cache nenachádza, resp. bola odstránená tesne pred tým, ako ste ju potrebovali ;)
  2. limit na minimálnu a maximálnu veľkosť cachovanného objektu: môže sa stať, že to, čo potrebujete, sa kvôli veľkosti nebude vôbec uchovávať

Pre lepšiu predstavu, ako približne funguje cachujúci proxy server pre WWW stránky, ponúkam tento model. Požiadavkou je URL, ktorú klient požaduje od proxy servera:

Nachádza sa stránka v cache pamäti?

  • ÁNO: Je odpoveď ešte stále platná? (zisťuje sa napr. čas poslednej modifikácie stránky)
    • ÁNO: proxy server vráti stránku zo svojej cache
    • NIE: proxy server aktualizuje kópiu stránky v cache a vráti ju klientovi
  • NIE: proxy server sa pokúsi stiahnuť stránku z cieľového servera. Podarilo sa stránku stiahnuť?
    • ÁNO: Vyhovuje stránka kritériám pre uloženie? (veľkosť, typ, direktívy pre proxy server, ...)
      • ÁNO: proxy server uloží stránku do cache a vráti ju klientovi
      • NIE: proxy server vráti stránku klientovi bez uloženia v cache
    • NIE: proxy vráti klientovi hlásenie o chybe

Proxy servery s cache sa používajú takmer výhradne na uchovávanie obsahu WWW stránok a preto sa odteraz budeme venovať iba nim.

7.1.3 Riadenie prístupu

Ak zabezpečíte, že všetky klientské počítače vo vašej sieti budú používať proxy server (pod Windows 9x sa to dá dosiahnuť iba pomocou zásahov do Registrov), stane sa jediným "úzkym hrdlom" komunikácie medzi klientom a serverom. Vznikne tak miesto v sieti, kde môžete pomocou pravidiel regulovať prístup k Internetu.

Výhody použitia proxy servera:

  1. možnosť nasadenia a vynucovania bezpečnostnej politiky z hľadiska prístupu k Internetu - napr. k určitým WWW stránkam
  2. jednoduché nastavenie bez nutnosti nastavovať politiky na všetkých klientoch

Nevýhody:

  1. výkon proxy servera má vplyv na rýchlosť prevádzky (čas odozvy na požiadavku)
  2. vzniká rizikové miesto na sieti ("single point of failure") - v prípade výpadku proxy servera sa nemožno dostať na Internet (toto možno riešiť pomocou viacerých proxy serverov v clustri, ale iba v prípade, že si môžete dovoliť mať viacero serverov)

 

7.2 Proxy server "Squid"

Predchádzajúce tri možnosti využitia proxy servera si predstavíme na populárnom a kvalitnom open-source proxy serveri pre cachovanie WWW stránok. Jeho meno je Squid (https://www.squid-cache.org).

Squid umožňuje klientom pracovať s protokolmi HTTP, HTTPS, FTP a podporuje aj niekoľko ďalších, menej používaných aplikačných protokolov.

Pred inštaláciou Squida si uvedomte, že prevažná časť činnosti proxy servera spočíva v uchovávaní objektov v pamäti a na disku. Čím viac budete mať pamäte (odporúčam najmenej 128 MB), tým rýchlejší bude Váš proxy server. Ak sa údaje budú uchovávať na disku, rýchlosť diskov rapídne ovplyvní výkon proxy servera. Používajte preto čo najrýchlejšie disky (SCSI alebo rýchle IDE, najlepšie je použiť RAID). 

7.2.1 Spúšťanie a zastavovanie Squida

Squid sa spúšťa automaticky pri štarte systému v niektorom runleveli, pretože nemá význam to robiť ručne. Čo však význam určite má, je jeho ovládanie z príkazového riadku v prípade údržby, upgrade, zmeny konfigurácie a podobne.

Ak používate "init" skripty, všetky operácie sú celkom jednoduché.

  • Spustenie Squida: /etc/init.d/squid start
  • Zastavenie Squida: /etc/init.d/squid stop
  • Reštartovanie Squida: /etc/init.d/squid restart
  • Opätovné načítanie konfiguračných súborov: /etc/init.d/squid reload

Ak "init" skripty nepoužívate, operácie sú len trošku odlišné (cesta závisí od inštalácie Squida):

  • Spustenie Squida: /usr/sbin/squid
  • Zastavenie Squida: /usr/sbin/squid -k shutdown
  • Opätovné načítanie konfiguračných súborov: /usr/sbin/squid -k reconfigure

Poznámka: "init" skripty sú iba rozhraním k ovládaniu Squida pomocou príkazového riadku. Môžete sa o tom presvedčiť preštudovaním "init" skriptu "/etc/init.d/squid".

7.2.2 Inicializácia adresárovej štruktúry cache

Po nainštalovaní Squida treba vytvoriť adresárovú štruktúru, v ktorej Squid uchováva obsah svojej cache (cachované súbory). Niektoré distribúcie vytvoria túto štruktúru automaticky pri inštalácii alebo prvom spustení (napr. Mandrake 9.0), ak to však nie je Váš prípad alebo ste Squid kompilovali zo zdrojových textov, musíte to spraviť ručne. Našťastie ide iba o jediný príkaz:

/usr/sbin/squid -z

Výsledkom je vytvorenie adresárovej štruktúry v adresári, ktorý ste uviedli v konfiguračnom súbore "/etc/squid.conf" (v niektorých distribúciách "/etc/squid/squid.conf"), štandardne je to "/var/spool/squid".

7.2.3 Konfiguračný súbor "/etc/squid.conf" ("/etc/squid/squid.conf")

Konfiguračný súbor obsahuje direktívy pre Squid. Každý riadok má tvar:

direktíva hodnota1 [hodnota2 hodnota3 ... hodnotaN]

Mnoho direktív má nastavené implicitné hodnoty, takže ich nemusíte ani odkomentovať (o tomto vás vždy informuje pokec v príslušnej časti konfiguračného súboru "squid.conf").

Súbor je veľmi dobre komentovaný a vrelo odporúčam prečítať si ho celý (pozor, je dosť veľký). Väčšina vecí je už nastavená a dokonca správne, ale parametre týkajúce sa zabezpečenia a nastavenia vlastností cache si musíte nastaviť sami. Ak to neurobíte, implicitné nastavenie proxy servera zabraňuje pripojenie používateľom z akejkoľvek adresy okrem "127.0.0.1". 

7.2.3.1 Nastavenia siete (sekcia NETWORK OPTIONS)

Nasledujúce nastavenia umožňujú určiť porty, na ktorých počúva Squid. Čím menej portov je otvorených, tým je nižšie riziko ich zneužitia. Niekoľko týchto portov väčšinou nepotrebujete, takže ich môžete zakázať.

  • http_port 3128: port, na ktorom Squid prijíma požiadavky klientov. Tento port je nevyhnutný pre činnosť Squida.
  • icp_port 3130: port, pomocou ktorého Squid spolupracuje s rovnocennými proxy servermi. Ak ich nepoužívate alebo neviete, čo to je, môžete túto funkciu zablokovať použitím hodnoty čísla portu "0"
  • htcp_port 4827: port, pomocou ktorého Squid spolupracuje s rovnocennými proxy servermi. Ak ich nepoužívate alebo neviete, čo to je, môžete túto funkciu zablokovať použitím hodnoty čísla portu "0"

 

7.2.3.2 Nastavenia cache (sekcia OPTIONS WHICH AFFECT THE CACHE SIZE)

Pomocou týchto nastavení môžete ovplyvniť veľkosť diskovej cache, objekty, ktoré sa nemajú uchovávať v cache a algoritmus odstraňovania objektov z cache v prípade, že treba uložiť nové objekty.

  • cache_mem 8 MB: veľkosť pamäte používaná na najviac používané objekty. Zväčšite hodnotu podľa vašich možností a nárokov. Pozor, nejde o pamäť, ktorú bude Squid zaberať! V skutočnosti bude proces "squid" zaberať v pamäti viac!
  • maximum_object_size 4096 KB: maximálna veľkosť objektu uchovávaného v cache. Väčšie objekty sa nebudú uchovávať!
  • minimum_object_size 0 KB: minimálna veľkosť objektu uchovávaného v cache. Menšie objekty sa nebudú uchovávať. Hodnota 0 znamená, že nenastavujete minimálnu hodnotu.
  • maximum_object_size_in_memory 8 KB: maximálna veľkosť objektu, ktorý má byť uchovávaný vo fyzickej pamäti
  • cache_replacement_policy lru: algoritmus odstraňovania objektov z cache (určuje, ktoré objekty budú odstránené, ak treba uchovať iný objekt). Default: lru (least recently used - najdlhšie nepoužité objekty). Pomocou tohto parametra môžete radikálne ovplyvniť výkon proxy servera, pravdepodobne to však vyžaduje rekompiláciu (balíčkové verzie nepodporujú všetky algoritmy) a naštudovanie tejto časti konfiguračného súboru (obsahuje aj adresy).
  • memory_replacement_policy lru: algoritmus odstraňovania objektov z fyzickej pamäti (ten istý princíp ako parameter "cache_replacement_policy")

 

7.2.3.3 Cesty k logom a cache (sekcia LOGFILE PATHNAMES AND CACHE DIRECTORIES)

Táto sekcia obsahuje nastavenia pre cesty k logom Squida a k adresáru so samotnou cache. Štandardné miesto pre uloženie cache je v adresári "/var/spool/squid", kde si pri prvom spustení vytvorí adresárovú štruktúru na uchovávanie cachovaných objektov. Je veľmi vhodné, ak je tento adresár (alebo "/var") na samostatnej partícii, ako sme o tom hovorili v kapitole "Rozdelenie disku".

  • cache_dir ufs /var/spool/squid 100 16 256: nastavenie adresára s cachovanými objektmi. Prvý parameter ("ufs") určuje spôsob uchovávania súborov, existujú aj iné typy, môžete experimentovať. Druhý parameter ("/var/spool/squid") určuje adresár, v ktorom sa uchovávajú objekty. Tretí parameter ("100") určuje veľkosť cache na disku (v megabajtoch, teda 100 je 100 MB). Posledné dva parametre určujú počet vytvorených adresárov nižšej úrovne v adresári s cache. Pri defaultnom nastavení sa vytvorí 16 podadresárov, každý z nich má 256 podadresárov, v ktorých sa uchovávajú objekty. Tieto adresáre sa vytvárajú pre zrýchlenie prístupu k objektom a nemali by ste do nich zasahovať! Pamätajte tiež, že po zmene hodnoty tejto direktívy treba znovu vytvoriť/upraviť adresárovú štruktúru cache (spustiť Squid s parametrom "-z").
  • cache_access_log /var/log/squid/access.log: logovací súbor so záznamami každej požiadavky
  • cache_log /var/log/squid/cache.log: logovací súbor so všeobecnými informáciami o správaní sa cache, môžete ho sledovať napr. po spustení proxy servera a dozviete sa, či je všetko OK
  • cache_store_log none: logovací súbor obsahujúci záznamy o objektoch, čase vloženia do cache, čase odstránenia a podobne. V konfiguračnom súbore je priamo zmienka o tom, že neexistujú seriózne utility na analýzu tohto súboru, takže ho môžete zakázať (hodnota "none").
  • emulate_httpd_log off: umožňuje zapnúť a vypnúť emuláciu formátu HTTP servera (Apache) v logu "cache_access_log". Emulovaný formát sa dá jednoduchšie čítať (správcom), ale pre prirodzený formát existujú nástroje na analýzu prístupov a podobne.

 

7.2.3.4 Vyladenie cache (sekcia: OPTIONS FOR TUNING THE CACHE)

  • request_body_max_size 1 MB: maximálna veľkosť HTTP požiadavky
  • reply_body_max_size 0: maximálna veľkosť odpovede. Umožňuje zablokovať sťahovanie veľkých súborov (MP3, filmy) cez Váš proxy server. Default: žiaden limit.

 

7.2.3.5 Riadenie prístupu pomocou ACL (access control lists)

Na kontrolu prístupu slúžia v nastavení Squida zoznamy na kontrolu prístupu (ACL - Access Control Lists). V ďalšom budem používať anglickú skratku ACL, ktorá je jednoduchá a najmä - je to skratka.

Každý ACL sa skladá najmenej zo štyroch častí:

acl meno typ hodnota ...
acl meno typ "súbor" ...
  1. direktíva acl
  2. meno ACL (budete sa naň odvolávať pri samotnom riadení prístupu)
  3. typ ACL (určuje, čo budete kontrolovať, napr. zdrojovú adresu, cieľovú adresu atď.)
  4. hodnota, prípadne viacero hodnôt. Hodnota je uvedená ako reťazec, prípadne môžete uviesť meno súboru v úvodzovkách - súbor musí byť obyčajný textový súbor, v ktorom každý riadok obsahuje jednu hodnotu.

Nasleduje zoznam najpoužívanejších typov ACL s uvedením ich syntaxe a krátkym popisom. Vynechal som len tie ACL, s ktorými som sa v praxi zatiaľ nestretol, všetky sú komentované v konfiguračnom súbore "/etc/squid.conf". Pripomínam, že cieľová adresa znamená adresa (HTTP) servera, zdrojová adresa je adresa klientského počítača, ktorý žiada od proxy servera sprístupnenie WWW stránky na danej cieľovej adrese.

  • acl aclname src 10.0.0.0/255.255.255.0 ...: definuje ACL založené na zdrojovej IP adrese a maske
  • acl aclname src 10.0.0.1-10.0.63/255.255.255.255 ...: definuje ACL pre zadaný rozsah zdrojových IP adries
  • acl aclname dst 192.168.0.0/255.255.255.0 ...: definuje ACL pre zadanú cieľovú IP adresu s maskou
  • acl aclname srcdomain .foo.com ...: definuje ACL pre zadanú časť domény v zdrojovej adrese (vykoná sa reverzný preklad zdrojovej adresy)
  • acl aclname dstdomain .foo.com ...: definuje ACL pre zadanú časť domény v cieľovej adresy (z URL adresy)
  • acl aclname srcdom_regex [-i] xxx ...: definuje ACL pre zdrojovú adresu (adresu klienta), ktorá vyhovuje regulárnemu výrazu. Parameter "-i" znamená, že sa nebude brať do úvahy veľkosť písmen.
  • acl aclname dstdom_regex [-i] xxx ...: definuje ACL pre cieľovú adresu (adresu servera), ktorá vyhovuje regulárnemu výrazu. Parameter "-i" znamená, že sa nebude brať do úvahy veľkosť písmen.
  • acl aclname time [day] [h1:m1-h2:m2]: definuje ACL pre čas - môžete určiť dni (S - Sunday, M - Monday, T - Tuesday, W - Wednesday, H - Thursday, F - Friday, A - Saturday) a časy (h1:m1 musí byť menej ako h2:m2).
  • acl aclname url_regex [-i] ^https://www.foo.com ...: definuje ACL pre URL, ktorá vyhovuje regulárnemu výrazu. Tu: URL musí začínať textom "https://www.foo.com"
  • acl aclname urlpath_regex [-i] \.gif$ ...: definuje ACL pre časť URL (cestu), ktorá vyhovuje regulárnemu výrazu. Tu: cesta musí končiť reťazcom ".gif"
  • acl aclname port 80 70 21 ...: definuje ACL pre cieľový port alebo viacero cieľových portov
  • acl aclname port 0-1024 ...: definuje ACL pre rozsah cieľových portov.
  • acl aclname proto HTTP FTP ...: definuje ACL pre typ protokolu.
  • acl aclname method GET POST ...: definuje ACL pre metódu protokolu HTTP.
  • acl aclname browser [-i] regexp: definuje ACL pre hlavičku "User-Agent" v protokole HTTP (umožňuje detekovať typ prehliadača), ktorá vyhovuje regulárnemu výrazu.

Príklady:

acl localnet src 10.0.0.0/255.255.255.0
acl localnet src 10.0.0.0/255.255.255.0 192.168.0.0/255.255.255.0
definuje ACL s názvom "localnet" pre zdrojové adresy 10.0.0.0/255.255.255.0 (v druhom príklade navyše aj 192.168.0.0/255.255.255.0) - toto ACL použijeme pre definíciu adries z lokálnej siete
acl forbiddenpages dstdomain www.foo.com
acl forbiddenpages dstdomain www.foo.com www.foobar.com
definuje ACL s názvom "forbiddenpages" pre cieľovú adresu "www.foo.com" - toto ACL použijeme pre definíciu "zakázanej" stránky (v druhom príklade definujeme v tomto ACL aj druhú adresu "www.foobar.com"
acl day1 time M 8:00-16:00
definuje ACL s názvom "day1" pre čas 8:00 - 16:00 v pondelok - toto ACL použijeme na zakázanie istých stránok počas pracovných hodín v pondelok. Analogicky definujeme aj iné dni.
acl day2 time T 8:00-16:00
acl day3 time W 8:00-16:00
acl day4 time H 8:00-16:00
acl day5 time F 8:00-16:00
ako predchádzajúce ACL, pre ostatné dni

Ukážka (odporúčanie) minimálnej konfigurácie od autorov Squida, viacmenej na ukážku ďalších ACL:

  #Recommended minimum configuration:
  acl all src 0.0.0.0/0.0.0.0
  acl manager proto cache_object
  acl localhost src 127.0.0.1/255.255.255.255
  acl SSL_ports port 443 563
  acl Safe_ports port 80		# http
  acl Safe_ports port 21		# ftp
  acl Safe_ports port 443 563	# https, snews
  acl Safe_ports port 70		# gopher
  acl Safe_ports port 210		# wais
  acl Safe_ports port 1025-65535	# unregistered ports
  acl Safe_ports port 280		# http-mgmt
  acl Safe_ports port 488		# gss-http
  acl Safe_ports port 591		# filemaker
  acl Safe_ports port 777		# multiling http
  acl CONNECT method CONNECT

Poznámka: ACL "Safe_ports" má rovnakú hodnotu, ako by boli všetky hodnoty uvedené v jednom ACL na jednom riadku.

Na samotné riadenie prístupu slúžia direktívy "http_acces" v tvare:

http_access allow|deny [!]aclname ...
  • direktíva http_access
  • kľúčové slovo allow alebo deny určujúce, či direktíva povoľuje alebo blokuje prístup
  • meno ACL, ktoré určuje, čo budeme povoľovať alebo blokovať. Ak je prvým znakom "!", význam ACL sa neguje. Ak uvediete viacero ACL (zoznam), vyhodnocujú sa tak, akoby medzi nimi bol operátor "AND" (musia platiť súčasne).

Na poradí direktív "http_access" záleží! Ak požiadavka na sprístupnenie nejakej stránky vyhovie niektorej z direktív, je povolená alebo zamietnutá. Preto je dôležité uvedomiť si dve zásady:

  • najprv uveďte direktívy obmedzujúce požiadavky prichádzajúce z Vašej siete
  • povoľte spracovanie požiadaviek prichádzajúcich z Vašej lokálnej siete
  • zakážte všetko ostatné ("http_access deny all")

Odporúčaná minimálna konfigurácia od autorov Squida:

  #Recommended minimum configuration:
  #
  # Only allow cachemgr access from localhost
  http_access allow manager localhost
  http_access deny manager
  # Deny requests to unknown ports
  http_access deny !Safe_ports
  # Deny CONNECT to other than SSL ports
  http_access deny CONNECT !SSL_ports
  #
  # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
  #
  # And finally deny all other access to this proxy
  http_access allow localhost
  http_access deny all

Všimnite si, že štandardné rozhodnutie "http_access deny all" spolu s "http_access allow localhost" umožní použitie proxy servera iba pre procesy, ktoré na ňom bežia. To nie je práve želaná konfigurácia, ale presne vystihuje základné bezpečnostné pravidlo "čo nie je povolené, je zakázané."

Upravená minimálna konfigurácia:

  #Recommended minimum configuration:
  #
  # Only allow cachemgr access from localhost
  http_access allow manager localhost
  http_access deny manager
  # Deny requests to unknown ports
  http_access deny !Safe_ports
  # Deny CONNECT to other than SSL ports
  http_access deny CONNECT !SSL_ports
  #
  # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS

  http_access allow localnet
  
  # And finally deny all other access to this proxy
  http_access allow localhost
  http_access deny all

Upravená minimálna konfigurácia s našimi ACL z príkladov:

  #Recommended minimum configuration:
  #
  # Only allow cachemgr access from localhost
  http_access allow manager localhost
  http_access deny manager
  # Deny requests to unknown ports
  http_access deny !Safe_ports
  # Deny CONNECT to other than SSL ports
  http_access deny CONNECT !SSL_ports
  #
  # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS

  
http_access deny forbiddenpages
http_access allow localnet
# And finally deny all other access to this proxy http_access allow localhost http_access deny all

Všimnite si, že direktívu "http_access deny forbiddenpages" sme vložili PRED direktívu povoľujúcu všetky pripojenia z vnútornej siete ("http_access allow localnet")! Na poradí spracovania záleží a takto sme dosiahli presne to, čo sme chceli: používatelia vo vnútornej sieti (definovanej pomocou ACL "localnet") môžu používať proxy server na prístup k ľubovoľným stránkam okrem tých, ktoré sme zablokovali.

Upravená minimálna konfigurácia s pridanými ACL pre riadenie prístupu k stránkam na základe času:

  #Recommended minimum configuration:
  #
  # Only allow cachemgr access from localhost
  http_access allow manager localhost
  http_access deny manager
  # Deny requests to unknown ports
  http_access deny !Safe_ports
  # Deny CONNECT to other than SSL ports
  http_access deny CONNECT !SSL_ports
  #
  # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS

  
http_access deny day1 forbiddenpages
http_access deny day2 forbiddenpages
http_access deny day3 forbiddenpages
http_access deny day4 forbiddenpages
http_access deny day5 forbiddenpages
http_access allow localnet
# And finally deny all other access to this proxy http_access allow localhost http_access deny all

Predchádzajúca konfigurácia znemožní prístup na stránky uvedené v ACL "forbiddenpages" v prípade, že používateľ žiada ich sprístupnenie počas pracovného týždňa (pondelok-piatok) v čase 8:00-16:00.

Poznámka: ak Vás zaráža, prečo som použil 5 direktív namiesto jednej "http_access deny day1 day2 day3 day4 day5 forbiddenpages": je to preto, že medzi hodnotami "http_access" sa vykonáva operácia "AND". V preklade to znamená, že by musel byť súčasne pondelok, utorok, streda, štvrtok, piatok, čas 8:00-16:00 a stránka z ACL "forbiddenpages". 

7.2.3.6 Ďalšie nastavenia 

Tieto direktívy nastavujú rozličné administratívne parametre.

  • cache_mgr root: e-mailová adresa správcu cache
  • cache_effective_user squid: používateľ, s ktorého právami bežia procesy Squida, ak bol spustený pod rootom. Odporúča sa vytvoriť špeciálneho používateľa (napr. "squid").
  • cache_effective_group squid: skupina, s ktorej právami beža procesy Squida, ak bol spustený pod rootom. Odporúča sa vytvoriť špeciálnu skupinu (napr. "squid").
  • memory_pools on: ak je táto voľba zapnutá, Squid si udržiava alokovanú (aj keď nevyužitú) pamäť pre ďalšie použitie. Ak máte málo pamäte, zakážte túto voľbu pomocou hodnoty "off".
  • memory_pools_limit 50 MB: veľkosť pamäte, ktorú si Squid udržiava alokovanú, ak používate "memory_pools".
  • error_directory /usr/lib/squid/errors/Slovak: adresár s chybovými hláseniami - default: angličtina, tu uvedená direktíva zabezpečí zobrazovanie slovenských chybových hlásení. Chybové hlásenia sú uložené ako samostatné HTML súbory, ktoré môžete ľubovoľne modifikovať a dopĺňat - nezabúdajte však, že pri aktualizácii Squida sa môžu prepísať! Ak potrebujete chybové hlásenia modifikovať, skopírujte si ich do iného adresára (typicky napr. "/usr/local/lib/squid/errors/Slovak").
  • snmp_port 0: ak nepoužívate SNMP, môžete zakázať ďalší port pomocou hodnoty "0"
  • chroot /chroot_jail: umožní uzavrieť Squid vo vyhradenom adresári (systémové volanie chroot()). Všetky cesty, ktoré Squid používa, sa stanú relatívnymi cestami od tohto adresára, teda napr. "/var/spool/squid" znamená /chroot_jail/var/spool/squid. Problémy pri použití chroot() spočívajú v tom, že ak proces používa dynamické knižnice, konfiguračné súbory, unixové zariadenia (devices), treba ich nakopírovať do zodpovedajúcich adresárov vo vyhradenom adresári "/chroot_jail". Obyčajne existujú kompletné zoznamy súborov pre toho-ktorého démona, ale aj tak je to väčšinou dosť náročné na odladenie. Default: vypnuté.
  • logfile_rotate: počet udržiavaných logovacích súborov pri používaní "squid -k rotate" (prípony predchádzajúcich logovacích súborov budú čísla). Tento príkaz sa volá automaticky pomocou programu "logrotate". Ak je hodnota parametra "logfile_rotate" rovná "0", nastavenie riadi program "logrotate". Odporúčam nastaviť na hodnotu "0" a použiť výhradne konfiguračné parametre súboru "/etc/logrotate.d/squid", inak sa vystavujete hľadaniu príčiny, prečo sa pre Squid uchováva iný počet predchádzajúcich logovacích súborov ako je uvedené v konfigurácii "logrotate"
  • append_domain: doména, ktorá sa pridá za nekompletné adresy v URL.

 

7.2.4 Ukážka reálneho súboru "squid.conf"

Pozor!!!
V nijakom prípade nepoužite tento konfiguračný súbor bez predchádzajúcej úpravy!!! Obsahuje adresy a údaje platné pre www.gafa.sk!

TODO: pridať komentáre aj do tohto výpisu

#	WELCOME TO SQUID 2
#	------------------
#
#	This is the default Squid configuration file. You may wish
#	to look at https://cache.is.co.za/squid/ for documentation,
#	or the Squid home page (https://squid.nlanr.net/) for the FAQ.
#
#	The default Squid config file shows what the defaults for
#	various options happen to be.  If you don't need to change the
#	default, you shouldn't uncomment the line.  Doing so may cause
#	run-time problems.  In some cases "none" refers to no default
#	setting at all, whilst in other cases it refers to a valid
#	option - the comments for that keyword indicate if this is the
#	case.
#
# NETWORK OPTIONS
# -----------------------------------------------------------------------------

#  TAG: http_port
#	The port number where Squid will listen for HTTP client
#	requests.  Default is 3128, for httpd-accel mode use port 80.
#	May be overridden with -a on the command line.
#
#	You may specify multiple ports here, but they MUST all be on
#	a single line.
#
http_port 3128

#  TAG: icp_port
#	The port number where Squid sends and receives ICP requests to
#	and from neighbor caches.  Default is 3130.  To disable use
#	"0".  May be overridden with -u on the command line.
#
#icp_port 3130
icp_port 0

#  TAG: htcp_port
#	The port number where Squid sends and receives ICP requests to
#	and from neighbor caches.  Default is 4827.  To disable use
#	"0".
#
#	To enable this option, you must use --enable-htcp with the
#	configure script.
#htcp_port 0

#  TAG: mcast_groups
#	This tag specifies a list of multicast groups which your server
#	should join to receive multicasted ICP requests.
#
#	NOTE!  Be very careful what you put here!  Be sure you
#	understand the difference between an ICP _query_ and an ICP
#	_reply_.  This option is to be set only if you want to RECEIVE
#	multicast queries.  Do NOT set this option to SEND multicast
#	ICP (use cache_peer for that).  ICP replies are always sent via
#	unicast, so this option does not affect whether or not you will
#	receive replies from multicast group members.
#
#	You must be very careful to NOT use a multicast address which
#	is already in use by another group of caches.  NLANR has been
#	assigned a block of multicast address space for use in Web
#	Caching.  Plese write to us at nlanr-cache@nlanr.net to receive
#	an address for your own use.
#
#	If you are unsure about multicast, please read the Multicast
#	chapter in the Squid FAQ (https://squid.nlanr.net/Squid/FAQ/).
#
#	Usage: mcast_groups 239.128.16.128 224.0.1.20
#
#	By default, Squid doesn't listen on any multicast groups.
#
#mcast_groups 239.128.16.128

#  TAG: tcp_incoming_address
#  TAG: tcp_outgoing_address
#  TAG: udp_incoming_address
#  TAG: udp_outgoing_address
#	Usage: tcp_incoming_address 10.20.30.40
#	       udp_outgoing_address fully.qualified.domain.name
#
#	tcp_incoming_address	is used for the HTTP socket which accepts
#				connections from clients and other caches.
#	tcp_outgoing_address	is used for connections made to remote
#				servers and other caches.
#	udp_incoming_address	is used for the ICP socket receiving packets
#				from other caches.
#	udp_outgoing_address	is used for ICP packets sent out to other
#				caches.
#
#	The default behaviour is to not bind to any specific address.
#
#	NOTE, udp_incoming_address and udp_outgoing_address can not
#	have the same value (unless it is 0.0.0.0) since they both use
#	port 3130.
#
#tcp_incoming_address 0.0.0.0
#tcp_outgoing_address 0.0.0.0
#udp_incoming_address 0.0.0.0
#udp_outgoing_address 0.0.0.0


# OPTIONS WHICH AFFECT THE NEIGHBOR SELECTION ALGORITHM
# -----------------------------------------------------------------------------

#  TAG: cache_peer
#	To specify other caches in a hierarchy, use the format:
#
#		hostname type http_port icp_port
#
#	For example,
#
#	#                                        proxy  icp
#	#          hostname             type     port   port  options
#	#          -------------------- -------- ----- -----  -----------
#	cache_peer parent.foo.net       parent    3128  3130  [proxy-only]
#	cache_peer sib1.foo.net         sibling   3128  3130  [proxy-only]
#	cache_peer sib2.foo.net         sibling   3128  3130  [proxy-only]
#
#	      type:  either 'parent', 'sibling', or 'multicast'.
#
#	proxy_port:  The port number where the cache listens for proxy
#		     requests.
#
#	  icp_port:  Used for querying neighbor caches about
#		     objects.  To have a non-ICP neighbor
#		     specify '7' for the ICP port and make sure the
#		     neighbor machine has the UDP echo port
#		     enabled in its /etc/inetd.conf file.
#
#	    options: proxy-only
#		     weight=n
#		     ttl=n
#		     no-query
#		     default
#		     round-robin
#		     multicast-responder
#		     closest-only
#		     no-digest
#		     no-netdb-exchange
#		     no-delay
#		     login=user:password
#
#		     use 'proxy-only' to specify that objects fetched
#		     from this cache should not be saved locally.
#
#		     use 'weight=n' to specify a weighted parent.
#		     The weight must be an integer.  The default weight
#		     is 1, larger weights are favored more.
#
#		     use 'ttl=n' to specify a IP multicast TTL to use
#		     when sending an ICP request to this address.
#		     Only useful when sending to a multicast group.
#		     Because we don't accept ICP replies from random
#		     hosts, you must configure other group members as
#		     peers with the 'multicast-responder' option below.
#
#		     use 'no-query' to NOT send ICP queries to this
#		     neighbor.
#
#		     use 'default' if this is a parent cache which can
#		     be used as a "last-resort." You should probably
#		     only use 'default' in situations where you cannot
#		     use ICP with your parent cache(s).
#
#		     use 'round-robin' to define a set of parents which
#		     should be used in a round-robin fashion in the
#		     absence of any ICP queries.
#
#		     'multicast-responder' indicates that the named peer
#		     is a member of a multicast group.  ICP queries will
#		     not be sent directly to the peer, but ICP replies
#		     will be accepted from it.
#
#		     'closest-only' indicates that, for ICP_OP_MISS
#		     replies, we'll only forward CLOSEST_PARENT_MISSes
#		     and never FIRST_PARENT_MISSes.
#
#		     use 'no-digest' to NOT request cache digests from
#		     this neighbor.
#
#		     'no-netdb-exchange' disables requesting ICMP
#		     RTT database (NetDB) from the neighbor.
#
#		     use 'no-delay' to prevent access to this neighbor
#		     from influencing the delay pools.
#
#		     use 'login=user:password' if this is a personal/workgroup
#		     proxy and your parent requires proxy authentication.
#
#	NOTE: non-ICP neighbors must be specified as 'parent'.
#
#cache_peer hostname type 3128 3130

#  TAG: cache_peer_domain
#	Use to limit the domains for which a neighbor cache will be
#	queried.  Usage:
#
#	cache_peer_domain cache-host domain [domain ...]
#	cache_peer_domain cache-host !domain
#
#	For example, specifying
#
#		cache_peer_domain parent.foo.net	.edu
#
#	has the effect such that UDP query packets are sent to
#	'bigserver' only when the requested object exists on a
#	server in the .edu domain.  Prefixing the domainname
#	with '!' means that the cache will be queried for objects
#	NOT in that domain.
#
#	NOTE:	* Any number of domains may be given for a cache-host,
#		  either on the same or separate lines.
#		* When multiple domains are given for a particular
#		  cache-host, the first matched domain is applied.
#		* Cache hosts with no domain restrictions are queried
#		  for all requests.
#		* There are no defaults.
#		* There is also a 'cache_peer_access' tag in the ACL
#		  section.

#  TAG: neighbor_type_domain
#	usage: neighbor_type_domain parent|sibling domain domain ...
#
#	Modifying the neighbor type for specific domains is now
#	possible.  You can treat some domains differently than the the
#	default neighbor type specified on the 'cache_peer' line.
#	Normally it should only be necessary to list domains which
#	should be treated differently because the default neighbor type
#	applies for hostnames which do not match domains listed here.
#
#EXAMPLE:
#	cache_peer  parent cache.foo.org 3128 3130
#	neighbor_type_domain cache.foo.org sibling .com .net
#	neighbor_type_domain cache.foo.org sibling .au .de

#  TAG: icp_query_timeout	(msec)
#	Normally Squid will automatically determine an optimal ICP
#	query timeout value based on the round-trip-time of recent ICP
#	queries.  If you want to override the value determined by
#	Squid, set this 'icp_query_timeout' to a non-zero value.  This
#	value is specified in MILLISECONDS, so, to use a 2-second
#	timeout (the old default), you would write:
#
#		icp_query_timeout 2000
#
#icp_query_timeout 0

#  TAG: mcast_icp_query_timeout	(msec)
#	For Multicast peers, Squid regularly sends out ICP "probes" to
#	count how many other peers are listening on the given multicast
#	address.  This value specifies how long Squid should wait to
#	count all the replies.  The default is 2000 msec, or 2
#	seconds.
#
#mcast_icp_query_timeout 2000

#  TAG: dead_peer_timeout	(seconds)
#	This controls how long Squid waits to declare a peer cache
#	as "dead."  If there are no ICP replies received in this
#	amount of time, Squid will declare the peer dead and not
#	expect to receive any further ICP replies.  However, it
#	continues to send ICP queries, and will mark the peer as
#	alive upon receipt of the first subsequent ICP reply.
#
#	This timeout also affects when Squid expects to receive ICP
#	replies from peers.  If more than 'dead_peer' seconds have
#	passed since the last ICP reply was received, Squid will not
#	expect to receive an ICP reply on the next query.  Thus, if
#	your time between requests is greater than this timeout, you
#	will see a lot of requests sent DIRECT to origin servers
#	instead of to your parents.
#
#dead_peer_timeout 10 seconds

#  TAG: hierarchy_stoplist
#	A list of words which, if found in a URL, cause the object to
#	be handled directly by this cache.  In other words, use this
#	to not query neighbor caches for certain objects.  You may
#	list this option multiple times.
#
#	The default is to directly fetch URLs containing 'cgi-bin' or '?'.
#
hierarchy_stoplist cgi-bin ?

#  TAG: no_cache
#	A list of ACL elements which, if matched, cause the reply to
#	immediately removed from the cache.  In other words, use this
#	to force certain objects to never be cached.
#
#	You must use the word 'DENY' to indicate the ACL names which should
#	NOT be cached.
#
#	There is no default.  We recommend you uncomment the following
#	two lines.
#
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY


# OPTIONS WHICH AFFECT THE CACHE SIZE
# -----------------------------------------------------------------------------

#  TAG: cache_mem	(bytes)
#	NOTE: THIS PARAMETER DOES NOT SPECIFY THE MAXIMUM PROCESS
#	SIZE.  IT PLACES A LIMIT ON ONE ASPECT OF SQUID'S MEMORY
#	USAGE.  SQUID USES MEMORY FOR OTHER THINGS AS WELL.
#	YOUR PROCESS WILL PROBABLY BECOME TWICE OR THREE TIMES
#	BIGGER THAN THE VALUE YOU PUT HERE 
#
#	'cache_mem' specifies the ideal amount of memory to be used
#	for:
#		* In-Transit objects
#		* Hot Objects
#		* Negative-Cached objects
#
#	Data for these objects are stored in 4 KB blocks.  This
#	parameter specifies the ideal upper limit on the total size of
#	4 KB blocks allocated.  In-Transit objects take the highest
#	priority.
#
#	In-transit objects have priority over the others.  When
#	additional space is needed for incoming data, negative-cached
#	and hot objects will be released.  In other words, the
#	negative-cached and hot objects will fill up any unused space
#	not needed for in-transit objects.
#
#	If circumstances require, this limit will be exceeded.
#	Specifically, if your incoming request rate requires more than
#	'cache_mem' of memory to hold in-transit objects, Squid will
#	exceed this limit to satisfy the new requests.  When the load
#	decreases, blocks will be freed until the high-water mark is
#	reached.  Thereafter, blocks will be used to store hot
#	objects.
#
#	The values of cache_mem_low and cache_mem_high (below) can be
#	used to tune the use of the memory pool.  When the high mark is
#	reached, in-transit and hot objects will be released to clear
#	space.  When an object transfer is completed, it will remain in
#	memory only if the current memory usage is below the low water
#	mark.
#
#	The default is 8 Megabytes.
#
cache_mem  12 MB

#  TAG: cache_swap_low	(percent, 0-100)
#  TAG: cache_swap_high	(percent, 0-100)
#	The low- and high-water marks for cache LRU replacement.  LRU
#	replacement begins when the high-water mark is reached and ends
#	when enough objects have been removed and the low-water mark is
#	reached. Defaults are 90% and 95%. If you have a large cache, 5%
#	could be hundreds of MB. If this is the case you may wish to
#	set these numbers closer together.
#
cache_swap_low  90
cache_swap_high 95

#  TAG: maximum_object_size	(bytes)
#	Objects larger than this size will NOT be saved on disk.  The
#	value is specified in kilobytes, and the default is 4MB.  If
#	you wish to get a high BYTES hit ratio, you should probably
#	increase this (one 32 MB object hit counts for 3200 10KB
#	hits).  If you wish to increase speed more than your want to
#	save bandwidth you should leave this low.
#
maximum_object_size 8192 KB

#  TAG: ipcache_size	(number of entries)
#  TAG: ipcache_low	(percent)
#  TAG: ipcache_high	(percent)
#	The size, low-, and high-water marks for the IP cache.
#
ipcache_size 1024
ipcache_low  90
ipcache_high 95

#  TAG: fqdncache_size	(number of entries)
#	Maximum number of FQDN cache entries.
fqdncache_size 1024


# LOGFILE PATHNAMES AND CACHE DIRECTORIES
# -----------------------------------------------------------------------------

#  TAG: cache_dir
#	Usage:
#	
#	cache_dir Directory-Name Mbytes Level-1 Level2
#
#	You can specify multiple cache_dir lines to spread the
#	cache among different disk partitions.
#
#	'Directory' is a top-level directory where cache swap
#	files will be stored.  If you want to use an entire disk
#	for caching, then this can be the mount-point directory.
#	The directory must exist and be writable by the Squid
#	process.  Squid will NOT create this directory for you.
#
#	If no 'cache_dir' lines are specified, the following
#	default will be used: /var/spool/squid.
#
#	'Mbytes' is the amount of disk space (MB) to use under this
#	directory.  The default is 100 MB.  Change this to suit your
#	configuration.
#
#	'Level-1' is the number of first-level subdirectories which
#	will be created under the 'Directory'.  The default is 16.
#
#	'Level-2' is the number of second-level subdirectories which
#	will be created under each first-level directory.  The default
#	is 256.
#
cache_dir ufs /var/spool/squid 640 16 256

#  TAG: cache_access_log
#	Logs the client request activity.  Contains an entry for
#	every HTTP and ICP request received.
#
cache_access_log /var/log/squid/access.log

#  TAG: cache_log
#	Cache logging file. This is where general information about
#	your cache's behaviour goes. You can increase the amount of data
#	logged to this file with the "debug_options" tag below.
#
cache_log /var/log/squid/cache.log

#  TAG: cache_store_log
#	Logs the activities of the storage manager.  Shows which
#	objects are ejected from the cache, and which objects are
#	saved and for how long.  To disable, enter "none". There are
#	not really utilities to analyse this data, so you can safely
#	disable it.
#
#cache_store_log /var/log/squid/store.log
cache_store_log none

#  TAG: cache_swap_log
#	Location for the cache "swap.log."  This log file holds the
#	metadata of objects saved on disk.  It is used to rebuild the
#	cache during startup.  Normally this file resides in the first
#	'cache_dir' directory, but you may specify an alternate
#	pathname here.  Note you must give a full filename, not just
#	a directory. Since this is the index for the whole object
#	list you CANNOT periodically rotate it!
#
#	If you have more than one 'cache_dir', these swap logs will
#	have names such as:
#
#		cache_swap_log.00
#		cache_swap_log.01
#		cache_swap_log.02
#
#	The numbered extension (which is added automatically)
#	corresponds to the order of the 'cache_dir' lines in this
#	configuration file.  If you change the order of the 'cache_dir'
#	lines in this file, then these log files will NOT correspond to
#	the correct 'cache_dir' entry (unless you manually rename
#	them).  We recommend that you do NOT use this option.  It is
#	better to keep these log files in each 'cache_dir' directory.
#
#cache_swap_log

#  TAG: emulate_httpd_log	on|off
#	The Cache can emulate the log file format which many 'httpd'
#	programs use.  To disable/enable this emulation, set
#	emulate_httpd_log to 'off' or 'on'.  The default
#	is to use the native log format since it includes useful
#	information that Squid-specific log analysers use.
#
emulate_httpd_log off

#  TAG: mime_table
#	Pathname to Squid's MIME table. You shouldn't need to change
#	this, but the default file contains examples and formatting
#	information if you do.
#
mime_table /usr/lib/squid/mime.conf

#  TAG: log_mime_hdrs	on|off
#	The Cache can record both the request and the response MIME
#	headers for each HTTP transaction.  The headers are encoded
#	safely and will appear as two bracketed fields at the end of
#	the access log (for either the native or httpd-emulated log
#	formats).  To enable this logging set log_mime_hdrs to 'on'.
#
#log_mime_hdrs off

#  TAG: useragent_log
#	If configured with the "--enable-useragent_log" configure
#	option, Squid will write the User-Agent field from HTTP
#	requests to the filename specified here.  By default
#	useragent_log is disabled.
#
#useragent_log none

#  TAG: pid_filename
#	A filename to write the process-id to.  To disable, enter "none".
#
pid_filename /var/run/squid.pid

#  TAG: debug_options
#	Logging options are set as section,level where each source file
#	is assigned a unique section.  Lower levels result in less
#	output,  Full debugging (level 9) can result in a very large
#	log file, so be careful.  The magic word "ALL" sets debugging
#	levels for all sections.  We recommend normally running with
#	"ALL,1".
#
debug_options ALL,1

#  TAG: log_fqdn	on|off
#	Turn this on if you wish to log fully qualified domain names
#	in the access.log. To do this Squid does a DNS lookup of all
#	IP's connecting to it. This can (in some situations) increase
#	latency, which makes your cache seem slower for interactive
#	browsing. 
#
#log_fqdn off

#  TAG: client_netmask
#	A netmask for client addresses in logfiles and cachemgr output.
#	Change this to protect the privacy of your cache clients.
#	A netmask of 255.255.255.0 will log all IP's in that range with
#	the last digit set to '0'.
#
client_netmask 255.255.255.255


# OPTIONS FOR EXTERNAL SUPPORT PROGRAMS
# -----------------------------------------------------------------------------

#  TAG: ftp_user
#	If you want the anonymous login password to be more informative
#	(and enable the use of picky ftp servers), set this to something
#	resonable for your domain, like wwwuser@somewhere.net
#
#	The reason why this is domainless by default is that the
#	request can be made on the behalf of a user in any domain,
#	depending on how the cache is used.
#	Some ftp server also validate that the email address is valid
#	(for example perl.com).
#
ftp_user Squid@

#  TAG: ftp_list_width
#	Sets the width of ftp listings. This should be set to fit in
#	the width of a standard browser. Setting this too small
#	can cut off long filenames when browsing ftp sites.
#
ftp_list_width 50

#  TAG: cache_dns_program
#	Specify the location of the executable for dnslookup process.
#
#NOT IN 2.3#cache_dns_program /usr/lib/squid/dnsserver

#  TAG: dns_children
#	The number of processes spawn to service DNS name lookups.
#	For heavily loaded caches on large servers, you should
#	probably increase this value to at least 10.  The maximum
#	is 32.  The default is 5.
#
#NOT IN 2.3#dns_children 5

#  TAG: dns_defnames	on|off
#	Normally the 'dnsserver' disables the RES_DEFNAMES resolver
#	option (see res_init(3)).  This prevents caches in a hierarchy
#	from interpreting single-component hostnames locally.  To allow
#	dnsserver to handle single-component names, enable this
#	option.
#
#dns_defnames off

#  TAG: dns_nameservers
#	Use this if you want to specify a list of DNS name servers
#	(IP addresses) to use instead of those given in your
#	/etc/resolv.conf file.
#
#	Example: dns_nameservers 10.0.0.1 192.172.0.4
#
#dns_nameservers none

#  TAG: unlinkd_program
#	Specify the location of the executable for file deletion process.
#	This isn't needed if you are using async-io since it's handled by
#	a thread.
#
unlinkd_program /usr/lib/squid/unlinkd

#  TAG: pinger_program
#	Specify the location of the executable for the pinger process.
#	This is only useful if you configured Squid (during compliation)
#	with the '--enable-icmp' option.
#
###pinger_program /usr/lib/squid/pinger

#  TAG: redirect_program
#	Specify the location of the executable for the URL redirector.
#	Since they can perform almost any function there isn't one included.
#	See the Release-Notes for information on how to write one.
#	By default, a redirector is not used.
#
#redirect_program none

#  TAG: redirect_children
#	The number of redirector processes to spawn. If you start
#	too few Squid will have to wait for them to process a backlog of
#	URLs, slowing it down. If you start too many they will use RAM
#	and other system resources.
#
#redirect_children 5

#  TAG: redirect_rewrites_host_header
#	By default Squid rewrites any Host: header in redirected requests.
#	If you are running a accelerator then this may not be a wanted effect
#	of a redirector.
#redirect_rewrites_host_header on

#  TAG: authenticate_program
#	Specify the command for the external authenticator.  Such a
#	program reads a line containing "username password" and replies
#	"OK" or "ERR" in an endless loop.  If you use an authenticator,
#	make sure you have 1 acl of type proxy_auth.  By default, the
#	authenticator_program is not used.
#
#	If you want to use the traditional proxy authentication,
#	jump over to the ../auth_modules/NCSA directory and
#	type:
#		% make
#		% make install
#
#	Then, set this line to something like
#
authenticate_program /usr/lib/squid/ncsa_auth /etc/squid_pwd
#
#authenticate_program none

#  TAG: authenticate_children
#	The number of authenticator processes to spawn (default 5). If you
#	start too few Squid will have to wait for them to process a backlog
#	of usercode/password verifications, slowing it down. When password
#	verifications are done via a (slow) network you are likely to need
#	lots of authenticator processes.
#
#authenticate_children 5

#  TAG: authenticate_ttl
#	The time a checked username/password combination remains cached
#	(default 3600). If a wrong password is given for a cached user,
#	the user gets removed from the username/password cache forcing
#	a revalidation.
#
#authenticate_ttl 3600


# OPTIONS FOR TUNING THE CACHE
# -----------------------------------------------------------------------------

#  TAG: wais_relay_host
#  TAG: wais_relay_port
#	Relay WAIS request to host (1st arg) at port (2 arg).
#
#wais_relay_host localhost
#wais_relay_port 8000

#  TAG: request_size	(KB)
#	Maximum allowed request size in kilobytes.  If people are using
#	POST to upload files, then set this to the largest acceptable
#	filesize plus a few extra kbytes.
#
#request_size 4096 KB

#  TAG: refresh_pattern
#	usage: refresh_pattern [-i] regex min percent max [options]
#
#	By default, regular expressions are CASE-SENSITIVE.  To make
#	them case-insensitive, use the -i option.
#
#	min and max are specified in MINUTES.
#	percent is an integer number.
#
#	options: override-expire
#		 override-lastmod
#		 reload-into-ims
#		 ignore-reload
#
#		override-expire enforces min age even if the server
#		sent a Expires: header. Doing this VIOLATES the HTTP
#		standard.  Enabling this feature could make you liable
#		for problems which it causes.
#
#		override-lastmod enforces min age even on objects
#		that was modified recently.
#
#		reload-into-ims changes client no-cache or ``reload''
#		to If-Modified-Since requests. Doing this VIOLATES the
#		HTTP standard. Enabling this feature could make you
#		liable for problems which it causes.
#
#		ignore-reload ignores a client no-cache or ``reload''
#		header. Doing this VIOLATES the HTTP standard. Enabling
#		this feature could make you liable for problems which
#		it causes.
#		
#	Please see the file doc/Release-Notes-1.1.txt for a full
#

                    

© 2009 Všetky práva vyhradené.

Vytvorte si web stránku zdarma!Webnode