Как я уже сказал, самым распространенным прокси-сервером является squid. Этот сервер имеет достаточно длинную историю, и за время его существования в нем реализовано много возможностей. Еще не было ничего такого, что я не смог бы получить с помощью squid.

Основной конфигурационный файл для squid — /etc/squid/squid.conf (в некоторых системах место его расположения /etc/squid.conf). Файл очень большой, и приводить его полностью нет смысла, т.к. значительную его часть занимают подробные комментарии по использованию директив.

Рассмотрим основные команды, которые нам доступны для управления прокси-сервером. Как обычно, все параметры, влияющие на производительность и безопасность, мы разберем подробно. Остальные настройки будут рассмотрены поверхностно, с ними можно поближе познакомиться по комментариям из конфигурационного файла.

 

9.3.1. HTTP-директивы

При подключении к Интернету пользователи первым делом стремятся загрузить Web-страничку. Если используется proxy, то необходимо правильно настроить HTTP-протокол. Для решения этой задачи в squid есть следующие директивы:

□ http_port n — параметр n определяет номер порта, через который будет происходить подключение.

Первое, что нам необходимо настроить, — это порты, на которых сервер будет ожидать подключения клиентов. Такие директивы имеют формат XXXX_port. Для порта HTTP запись будет выглядеть таким образом:

http_port 8080

После этого при конфигурировании браузера на клиентском компьютере вы должны будете указывать IP-адрес сервера, где установлен squid, и выделенный в данной директиве порт;

□ hierarchy_stoplist — определяет перечень URL-адресов, данные по которым всегда должны получаться с сервера, а не из кэша. Я рекомендую добавить в этот список слова "cgi-bin" и вопросительный знак. Адреса URL, содержащие такой текст, указывают на сценарии, которые могут исполняться на сервере, и их результат желательно не кэшировать.

Рассмотрим пример. Предположим, что вы прочитали Web-страницу www.servername.com/cgi-bin/ping.cgi, на которой можно через Web-интерфейс выполнить директиву ping. Допустим, что при первом обращении вы запустили команду ping к адресу 18.1.1.1. Результат будет сохранен в кэше прокси-сервера. В следующий раз вы обращаетесь к сценарию, чтобы выполнить ping 18.1.1.18, но браузер вернет первый результат, потому что возьмет его из своего кэша.

Страницы со сценариями могут возвращать разный результат, в зависимости от ситуации и параметров, которые выбрал пользователь. Если кэшировать такие страницы, то вы всегда будете видеть одно и то же. В результате вы получите только неудобства от соединения через proxy.

Вопросительный знак очень часто используется для передачи параметров в сценарии PHP, поэтому такие страницы тоже не рекомендуется кэшировать.

Тег hierarchy_stoplist запрещает брать страницу из кэша, а следующие две строки задают правило, по которому страницы с URL-адресом, содержащие слова "cgi-bin" или вопросительный знак, вообще не будут кэшироваться:

acl QUERY urlpath_regex cgi-bin \?

no_cache deny QUERY

Я думаю, вы согласитесь со мной, что незачем кэшировать то, что будет получаться с сервера, и зря расходовать дисковое пространство.

 

9.3.2. FTP-директивы

Для работы по FTP-протоколу тоже есть несколько директив:

□ ftp_passive параметр — режим работы. Если в качестве параметра указано значение on, то разрешен пассивный режим (устанавливается по умолчанию).

Сервер squid позволяет работать с FTP-протоколом, но может потребоваться некоторая настройка. Например, если squid находится за сетевым экраном, запрещающим пассивный режим, то лучше изменить значение параметра по умолчанию, установив для этого следующую директиву:

ftp_passive off

□ ftp_user адрес — определяет E-mail-адрес, который будет использоваться в качестве пароля при авторизации на анонимном FTP-сервере.

Ни один сервер не может точно сказать, правильно ли вы указали адрес, поэтому проверка может быть отключена. Но некоторые FTP-серверы проверяют корректность написания адреса. По умолчанию squid использует в качестве E-mail слово squid@:

ftp_user squid@

Правда, по умолчанию в файле /etc/squid/squid.conf эта строка закомментирована, но желательно поменять в ней E-mail-адрес, например:

ftp_user [email protected]

Такой адрес любой FTP-сервер воспримет как корректный, потому что он соответствует всем правилам написания E-mail;

□ ftp_list_width n — число n задает ширину листинга при просмотре содержимого FTP-сервера. Это значение должно быть достаточным, чтобы увидеть все файлы. Если установить слишком маленькое значение, то имена файлов будут обрезаться.

 

9.3.3. Настройка кэша

От того, как вы настроите кэш, будет зависеть удобство работы через прокси- сервер, поэтому я постараюсь показать все директивы, которые относятся к этому разделу, и подробно рассмотреть каждую из них:

□ cache_dir тип директория размер L1 L2 опции — определяет параметры директории, в которой будет храниться кэш. Основными для нас являются тип, директория и размер. В большинстве случаев для типа применяется значение ufs, но если вы используете асинхронный ввод/вывод (я не советую, потому что вызывает проблемы в работе), то может быть установлено aufs.

В качестве директории вы должны выбрать такую, которая находится в самом большом разделе, чтобы информация не разобщалась по нескольким дискам. Если у вас используется один диск с одним разделом, то расположение не имеет особого значения.

Размер директории по умолчанию равен 100 Мбайтам. Этого достаточно для ускорения работы трех пользователей. Если в вашей сети много пользователей и у каждого свои вкусы (любимые сайты), то значение желательно увеличить. Я использую не менее 1 Гбайта кэша. Выделенное пространство быстро исчезает, если серверу разрешено кэшировать большие файлы.

□ cache_mem n MB — задает максимальный размер оперативной памяти, необходимый для программы. По умолчанию используется n=8 Мбайт. Если ваш сервер решает задачи только proxy, то можно указать значение, равное разнице объемов оперативной памяти и памяти, необходимой для ОС. Например, если у вас ОЗУ 512 Мбайт, то для ОС в текстовом режиме 64 Мбайта будет более чем достаточно. Остальную память (448 Мбайт) можно отдать прокси-серверу — чем больше у него оперативной памяти, тем быстрее он сможет отвечать на часто запрашиваемые страницы;

□ cache_swap low n — процент заполнения кэша. Когда размер кэша превышает значение n, сервер начинает чистить его, убирая устаревшие объекты, пока размер не станет удовлетворять параметру;

□ cache_swap_high n — процент заполнения кэша. Команда аналогична предыдущей, но сервер начинает освобождать кэш более интенсивно. Это необходимо, чтобы не возникла ситуация, когда кэш будет переполнен;

□ minimum_object_size n KB — минимальный размер объекта, попадающего в кэш. По умолчанию установлено значение 0, при котором порог отсутствует;

□ maximum_object_size n KB — максимальный размер объекта, который должен кэшироваться. По умолчанию стоит значение 4096 Кбайт, что соответствует 4 Мбайтам. Для повышения производительности сервера необходимо понизить это значение, но тогда вы можете потерять на расходовании трафика. Если экономия трафика стоит более остро, то значение n необходимо увеличить;

□ maximum_object_size_in_memory n KB — максимальный размер объекта в памяти. По умолчанию установлено значение 8 Кбайт;

□ ipcache_size n — размер кэша для хранения IP-адресов. По умолчанию используется значение 1024 Кбайт;

□ ipcache_low n и ipcache_high n — соответственно минимальный и максимальный проценты заполнения кэша для IP-адресов;

□ reference_age параметр — время жизни объекта в кэше. Если объект пролежал дольше, то его можно удалять по старости. Рассмотрим несколько примеров использования директивы:

reference_age 1 week

reference_age 3.5 days

reference_age 4 months

reference_age 2.2 hours

По умолчанию используется значение в один год:

reference_age 1 week

□ quick_abort_min n KB — минимальный размер объекта, устанавливающий при обрыве соединения необходимость закончить его скачивание и полностью сохранить. Это позволяет сократить трафик и значительно увеличить скорость работы в сети. Например, пользователь запустил на скачивание файл для проверки соединения и оборвал связь. Если сервер успел сохранить файл, то при повторной попытке не надо снова скачивать те же данные. Достаточно их взять из кэша. По умолчанию установлено значение 16. Поставьте -1, чтобы отключить эту возможность;

□ quick_abort_max n KB — максимальный остаток объекта, при котором закачка будет прервана в случае обрыва соединения. По умолчанию установлено значение 16;

□ quick_abort_pct n — параметр аналогичен quick_abort_min n, но в данном случае указывается максимальный процент уже полученной информации;

□ negative_ttl n minutes — количество минут, которые нужно кэшировать негативный ответ сервера. Например, пользователь зашел на сервер и получил ошибку, которая может быть временной, поэтому нельзя кэшировать ответ на длительный срок. Значение по умолчанию 5 минут. Если пользователь обратится по этому же адресу по истечении этого времени, то копия из кэша не будет использоваться, а произойдет попытка вновь зайти на сайт;

□ positive_dns_ttl n hours — время в часах, в течение которого нужно кэшировать положительный результат DNS-запроса. В этот промежуток времени при повторных обращениях к DNS IP-адрес будет взят из кэша. По умолчанию используется значение 6 часов, в настоящее время его можно увеличить до 24 часов. Несколько лет назад IP-адреса имели тенденцию очень часто меняться, поэтому приходилось ограничивать время жизни запросов. Сейчас большинство сайтов имеют статичный адрес, который изменяется только при смене хостинга, а крупные порталы зарезервировали себе собственные постоянные IP-адреса. Если вы не хотите использовать кэширование IP-адресов, встроенное в squid, то можно установить этот параметр в 0;

□ negative_dns_ttl n minutes — промежуток времени в минутах, в пределах которого нужно кэшировать негативный ответ DNS-сервера. Если не найден DNS-адрес, то это может быть проблема с самим сервером имен, а не сайтом. Такие вопросы, чаще всего, решаются в течение 2–3 минут, поэтому отрицательный ответ не стоит держать в кэше дольше, иначе все это время клиенты не смогут обратиться к сайту. Я делаю этот параметр равным 1 или нулевым, чтобы пользователи увидели нужный сайт сразу после устранения проблемы;

□ range_offset_limit n KB — параметры кэширования. Если указать значение -1, то сервер загрузит из Интернета требуемый объект полностью, а потом будет транслировать пользователю полученные данные уже из собственного кэша. При значении о информация в запрошенном объеме будет передаваться между сервером и клиентом без кэширования на прокси- сервере, т.е. ни грамма лишнего. Если указано число более о, то proxy может кэшировать с интернет-сервера указанное количество килобайт. Например, пользователь запрашивает файл размером в 1 Мбайт и squid разрешено подкачивать 100 Кбайт, которые он сразу же может кэшировать. Это удобно, если пользователь не прервет передачу и не откажется забирать эту порцию, иначе получится, что сервер потратил трафик зря.

 

9.3.4. Журналы

В конфигурационном файле есть несколько параметров, влияющих на работу прокси-сервера с журналом (легко читаются в любом текстовом редакторе):

□ cache_access_log файл — журнал, в котором сохраняется вся активность пользователей, а именно HTTP- и ICP-запросы. По умолчанию этот параметр равен /var/log/squid/access.log;

□ cache_log файл — файл для хранения основной информации о кэше. По умолчанию используется /var/log/squid/cache.log;

□ cache_store_log файл — журнал операций над объектами в кэше (убраны или помещены, на какое время). По умолчанию используется файл /var/log/squid/store.log, но вы без проблем можете отключить этот журнал, указав в качестве значения none, потому что нет утилит для анализа сохраняемых данных, да и пользы в них мало, только расходы на сохранение;

□ log_mime_hdrs параметр — если в качестве параметра указано on, то в журнале access будут сохраняться заголовки MIME;

□ useragent_log — журнал, в котором сохраняется поле User-agent заголовков HTTP. Смысла в этом поле нет, потому что его легко подделать, и ничего полезного журнал не даст, поэтому по умолчанию он не используется.

В разд. 12.5 мы будем говорить о журналах Linux и различных сервисах, а в разд. 12.5.4 подробно рассмотрим содержимое основного журнала squid — /var/log/squid/access.log.

 

9.3.5. Разделение кэша

Чтобы ваш сервер мог обмениваться запросами с другими squid-серверами, разделяя таким образом содержимое кэша, вы должны настроить соответствующий протокол.

Дня этого есть следующие директивы:

□ icp_port n — номер порта, который будет использоваться для ICP-протокола. По умолчанию установлено значение 3130. Если указать 0, то протокол будет заблокирован;

□ htcp_port n — номер порта, который будет использоваться для ICP-протокола, работающего поверх TCP/IP. По умолчанию принято значение 4827. Если указать 0, то протокол будет заблокирован;

□ cache_peer адрес тип http_порт icp_порт опции — сервер, с которым можно обмениваться информацией. В качестве адреса указывается имя (или адрес) сервера, с которым предполагается взаимодействие. Параметр http_порт определяет порт, на котором настроен HTTP-прокси, и соответствует параметру http_port в файле конфигурации squid. Атрибут icp_порт определяет порт, на котором настроен ICP-протокол, и соответствует параметру icp_port в файле конфигурации squid удаленной системы. В качестве типа может указываться одно из следующих значений:

 • parent — старший в иерархии;

 • sibling — равнозначный;

 • multicast — широковещательный.

Последний параметр опции может принимать много различных значений, поэтому мы его рассматривать не будем, чтобы не тратить место в книге. В комментариях, содержащихся в конфигурационном файле, каждый параметр подробно описан;

□ icp_query_timeout n — время ожидания в миллисекундах. Чаще всего, прокси-серверы расположены в локальной сети с высокой скоростью доступа, и ожидание более 2000 мс будет лишним. В случае если ответ не будет получен и придется обращаться в Интернет, пользователь ощутит большую задержку;

□ cache_peer_domain хост домен — разрешить для хоста работу только с указанными доменами. Например, следующая строка позволит брать из кэша только то, что относится к домену com:

cache_peer_domain parent.net .com

Все остальные запросы будут игнорироваться, чтобы не перегружать сервер лишней работой. С помощью этого параметра можно настроить в сети несколько прокси-серверов, где каждый будет отвечать за свой домен.

 

9.3.6. Дополнительно

Рассмотрим оставшиеся параметры, которые я не смог отнести к определенным категориям, но представляющие для нас ценность:

□ redirect_rewrites_host_header параметр — позволяет (on) или запрещает (off) изменять поле Host в заголовках запросов. Если изменение разрешено, то сервер работает в анонимном режиме, иначе — в прозрачном. Анонимный режим требует дополнительных затрат, но позволяет использовать всего один IP-адрес для внешних соединений в сети любого размера. Прозрачный режим работает быстрее, но каждый компьютер должен иметь IP-адрес для работы с Интернетом;

□ redirector_access список — перечень запросов, проходящих через redirector. По умолчанию установлены все запросы;

□ cache_mgr_email — E-mail-адрес, на который будет послано письмо в случае возникновения проблем с работой proxy;

□ append domain домен — домен по умолчанию. Например, чаще всего пользователи работают с адресами домена com. Вполне логичным будет указать в директиве именно его (append_domain .com). Если пользователь потом введет адрес redhat, то squid сам добавит имя домена, и вы попадете на сайт redhat.com;

□ smtp_port n — номер порта, на котором нужно ожидать SMTP-запросы для отправки сообщений. Конечно же, SMTP — это такой протокол, который не требует кэширования, и работа через прокси-сервер не сэкономит трафик, но возможность может оказаться полезной, если нельзя устанавливать шлюз, а разрешен только proxy;

□ offline_mode параметр — режим работы. Если параметр равен on, то squid будет взаимодействовать только с кэшем, и обращений к Интернету не будет. Если запрашиваемой страницы в кэше нет, то пользователь увидит ошибку. Чтобы squid мог адресоваться к Интернету, необходимо установить параметр off (установлено по умолчанию).

 

Это самая больная тема для любого администратора. Да, и в squid тоже есть права доступа, и они также описываются в конфигурационном файле /etc/squid/squid.conf. Но мы рассматриваем права отдельно, потому что основной упор делаем на безопасность. Именно поэтому этой теме отведен отдельный раздел.

 

9.4.1. Список контроля доступа

Первое, с чем нам предстоит познакомиться, — это ACL (Access Control List, список контроля доступа), который предоставляет большие возможности для дальнейшей настройки прав доступа к сайтам. С помощью списка имен вы как бы группируете действия или пользователей. Используйте для этого следующую команду:

acl имя тип параметр

У данной директивы три параметра:

□ имя — задается любым, и лучше всего, если оно будет описывать выполняемые действия;

□ параметр — это шаблон или строка, смысл которой зависит от типа записи (второй аргумент);

□ тип — можно указывать следующие значения: src, dst, srcdomain, dstdomain, url_pattern, urlpath_pattern, time, port, proto, proxy_auth, method, browser, user. Рассмотрим основные типы, которые вам пригодятся при формировании последнего параметра (шаблона):

 • src — задаются IP-адреса пользователей;

 • dst — указываются адреса серверов;

 • port — определяется номер порта;

 • proto — описывается список протоколов (через пробел);

 • method — указывается используемый метод, например POST, GET и т.д.;

 • proxy_auth — определяется список имен пользователей, значения разделяются пробелами. В качестве имени можно использовать REQUIRED, чтобы принимались любые авторизованные записи (acl password proxy_auth REQUIRED);

 • url_regex — устанавливается URL или регулярное выражение для URL;

 • time — задается время в формате дни h1:m1-h2:m2. С помощью такой записи можно ограничить доступ только определенными днями недели и обусловленным временем. В качестве дней недели можно указывать: S — Sunday, M — Monday, T — Tuesday, W — Wednesday, H — Thursday, F — Friday, A — Saturday.

В файле конфигурации уже описано несколько правил, которые готовы к использованию и в большинстве случаев не требуют вмешательства. Их вы можете увидеть в листинге 9.1.

Листинг 9.1. Список acl-правил, описанных по умолчанию в конфигурационном файле /etc/squid/squid.conf

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

Это список прав доступа, необходимых для минимальной работы прокси-сервера.

Рассмотрим первую строку. Здесь задается acl с именем all. Так как используется тип шаблона src, то этому списку принадлежат юзеры, у которых IP-адрес соответствует 0.0.0.0/0.0.0.0, т.е. все пользователи.

Следующая строка создает ACL-запись с именем manager. Она определяет доступ к протоколу, потому что тип записи proto, а последний параметр задает протокол — cache_object. И так далее.

Давайте попробуем задать свою ACL-запись. Допустим, что в вашей сети есть 10 компьютеров с адресами от 192.168.8.1 до 192.168.8.10 (маска подсети 255.255.255.0), которым разрешен доступ к Интернету. Всем остальным нужно запретить.

Уже при создании списка вы должны отталкиваться от идеи, что изначально доступ запрещен всем, и позволять только тем, кому это действительно нужно. Итак, строка для всех у нас уже есть, и ее имя all. Для списка из 10 компьютеров создадим запись с именем AllowUsers, и ее описание будет следующим:

acl AllowUsers src 192.168.8.1-192.168.8.10/255.255.255.0

Эта запись относится к типу src, значит, сюда включаются все компьютеры с адресами, указанными в качестве последнего параметра.

 

9.4.2. Определение прав

После описания списков можно указать права доступа для каждого из них с помощью следующих команд:

□ http_access разрешение имя — определяет права доступа по протоколу HTTP. В качестве параметра разрешение можно указывать allow (доступ разрешен) или deny (доступ запрещен). Последний аргумент — это имя ACL-записи. В следующем примере запрещается доступ по протоколу HTTP всем пользователям, кроме указанных в ACL-записи AllowUsers:

http_access deny all

http_access allow AllowUsers

Указав права доступа для списка AllowUsers, мы одной строкой даем разрешение для всех компьютеров, входящих в данный ACL. Таким образом, нет необходимости прописывать права каждому компьютеру в отдельности. Это значительно облегчает жизнь администраторов в больших сетях.

В предыдущем примере (см. разд. 9.4.1) мы разрешили доступ к Интернету с IP-адресов только из диапазона 192.168.8.1–192.168.8.10, и если к прокси-серверу обратится компьютер с другим адресом, то в доступе будет отказано;

□ icp_access разрешение имя — описывает разрешение доступа к прокси-серверу по протоколу ICP. По умолчанию доступ запрещен для всех:

icp_access deny all

□ miss_access разрешение имя — описывает разрешение на получение ответа MISSES. В следующем примере только локальным пользователям дано право получать ответ MISSES, а все остальные могут принимать только HITS:

acl localclients src 172.16.0.0/16

miss_access allow localclients

miss_access deny !localclients

 

9.4.3. Аутентификация

Защита по IP-адресу не гарантирует от его подделки злоумышленником. К тому же, остается вероятность, что кто-то получит физический доступ к компьютеру, имеющему выход во всемирную сеть, и сделает нечто недозволенное.

Мне довелось работать в фирме, где каждому сотруднику было разрешено скачивать из сети определенное количество мегабайт. Проверка проходила через IP-адрес, и при превышении лимита руководство требовало от работника покрыть расходы за сверхнормативный трафик. Это нормальная ситуация, потому что работодатель не должен оплачивать бессмысленные прогулки сотрудника в Интернете. На работу приходят, чтобы выполнять свои обязанности, а не подыскивать обои для собственного компьютера.

Внимание!

Аутентификация не работает, если squid настроен на работу в прозрачном режиме.

Однажды у некоторых работников оказалось большое превышение трафика. Вроде бы ничего удивительного, но настораживало то, что эти товарищи были в отпуске. Кто-то подделывал чужой адрес и использовал служебный Интернет в своих целях.

Чтобы вы не столкнулись с подобной ситуацией, необходимо привязываться не только к IP-адресу, но и строить дополнительную защиту через проверку имени пользователя и пароля. Для аутентификации необходимо определить следующие директивы:

□ authenticate_program программа файл — задает программу аутентификации (по умолчанию не устанавливается) и файл паролей. Если вы хотите использовать традиционную программу аутентификации proxy, то можно указать следующую строку:

authenticate_program /usr/lib/squid/ncsa_auth /usr/etc/passwd

Путь к программе ncsa_auth в вашей системе может отличаться.

Чтобы использовать возможности аутентификации прокси-сервера, у вас должна присутствовать хотя бы одна ACL-запись типа proxy_auth;

□ authenticate_children n — определяет количество параллельно работающих процессов аутентификации. Один процесс не сможет производить проверку нескольких клиентов, поэтому если какой-либо пользователь проходит аутентификацию, то другие не смогут получить доступ к Интернету через сервер squid;

□ authenticate_ttl n hour — срок (в часах) хранения в кэше результата аутентификации. В течение этого времени пользователь может работать без повторной проверки. По умолчанию установлен 1 час, но если введен неправильный пароль, то запись удаляется из кэша;

□ authenticate_ip_ttl 0 second — связывает IP-адрес с аутентификацией. Необходимо установить 0, чтобы пользователи не могли воспользоваться одним и тем же паролем с разных IP-адресов. Некоторые клиенты считают, что можно делиться паролем с друзьями. Не стоит этого делать, потому что за это отвечает администратор. Если в вашей сети есть dialup-пользователи, подключающиеся с помощью модема, то это значение можно увеличить до 60 секунд, чтобы при разрыве связи была возможность перезвонить. Но обычно при подключении Dial-up используются динамические IP-адреса, которые выдаются при каждом соединении, и нет гарантии, что после повторного звонка адрес сохранится;

□ authenticate_ip_ttl_is_strict параметр — если параметр равен on, то доступ с других IP-адресов запрещен, пока время, указанное в authenticate_ip_ttl, не выйдет.

 

Сейчас нам предстоит немного поговорить о некоторых вопросах безопасности сервиса squid и дополнительных возможностях, которые могут ускорить работу в Интернете.

 

9.5.1. Безопасность сервиса

Когда я впервые знакомился с документацией на squid, то мне очень понравились следующие два параметра: cache_effective_user и cache_effective_group. Если squid запущен от имени администратора root, то идентификаторы пользователя и группы будут заменены на указанные в этих параметрах. По умолчанию установлено значение идентификатора squid для пользователя и для группы:

cache_effective_user squid

cache_effective_group squid

Таким образом, squid не будет работать с правами root, и при попытке сделать это сервис сам понизит свои права до squid. Не стоит вмешиваться. Сервису squid не имеет смысла давать большего, потому что ему достаточно прав только на директорию с кэшем.

 

9.5.2. Ускорение сайта

Сервис squid может ускорить работу определенного сайта, функционируя как httpd-акселератор. Для этого необходимо указать, как минимум, три параметра: адрес форсируемого сервера, который надо кэшировать, его порт и атрибуты сервера, который надо ускорять. Это задается с помощью следующих директив:

□ httpd_accel_host адрес — адрес реального сервера;

□ httpd_accel_port порт — порт Web-сервера. Чаще всего это порт по умолчанию (он равен 80), если не указан другой;

□ httpd_accel_uses_host_header параметр — HTTP-заголовок включает в себя поле Host, не проверяемое сервером squid, и это может оказаться большой дырой в безопасности. Разработчики рекомендуют отключать эту директиву, указав в качестве параметра значение off. Включать ее необходимо, если squid работает в прозрачном режиме;

□ httpd_accel_with_proxy параметр — флаг использования кэширования страницы для дополнительного повышения скорости (on/off).

 

9.5.3. Маленький секрет User Agent

Многие статистические системы не учитывают или не пускают к себе пользователей, запросы которых содержат пустое значение в поле User Agent. Именно так определяется, что вы работаете через proxy.

Опять случай из собственной практики. Я снова вспоминаю фирму, где мне пришлось работать 4 года, и защита была организована по IP-адресу. Мой отдел занимался автоматизацией производства, и в нем работали электронщики, а я был единственный программист и администратор в одном лице. Доступ в Интернет был разрешен только мне, начальнику отдела и его заместителю. Через несколько часов доступ имели все сотрудники отдела. Как это произошло? Решение очень простое — я поставил на свой компьютер прокси-сервер, к которому могли подключаться без аутентификации мои сослуживцы, а он уже переправлял эти запросы корпоративному proxy. Так как все запросы шли от меня, то главный proxy ничего не заметил.

На первый взгляд решение идеальное, но тут есть один изъян. Да, это поле User Agent, которое становится пустым при прохождении пакетов через мой squid-сервис. Но поле можно задать вручную в конфигурационном файле. Для этого существует директива fake_user_agent. Например, следующая строка может эмулировать запросы, как будто они идут от браузера Netscape:

fake_user_agent Netscape/1.0 (CP/M; 8-bit)

 

9.5.4. Защита сети

Сервис squid может быть как средством защиты сети, так и орудием проникновения хакера в сеть. Чтобы внешние пользователи не могли задействовать прокси-сервер для подключения к компьютерам локальной сети, необходимо добавить в конфигурационный файл следующие строки:

tcp_incoming_address внутренний_адрес

tcp_outgoing_address внешний_адрес

udp_incoming_address внутренний_адрес

udp_outgoing_address внешний_адрес

В данном случае внутренний_адрес — это адрес компьютера с установленным squid, сетевое соединение которого направлено на вашу локальную сеть, а внешний_адрес — это адрес сетевого соединения, направленного в Интернет. Если неправильно указать адреса, то хакер сможет подключаться к компьютерам локальной сети, находясь за ее пределами. Вот пример ошибочного конфигурирования squid-сервиса:

tcp_incoming_address внешний_адрес

tcp_outgoing_address внутренний_адрес

udp_incoming_address внешний_адрес

udp_outgoing_address внутренний_адрес

 

9.5.5. Борьба с баннерами и всплывающими окнами

В фирме, где я работал, появился новый сотрудник, и в первую неделю мы ощутили увеличение трафика. Это бывает со всеми, потому что любой новый пользователь Интернета начинает смотреть все страницы подряд. Со временем интерес стихает, и трафик понижается.

Мы уже говорили о том, что на любом сайте большую часть трафика отнимает графика. В большинстве браузеров отображение картинок можно отключить, но после этого путешествие будет не очень удобным. Некоторые сайты без графики теряют информативность, и с ними сложнее работать, поэтому отказаться совсем от этого режима невозможно.

Но есть графика, которая надоедает, раздражает и не несет полезной информации, а главное, от нее можно избавиться. Я говорю про баннеры. Давайте рассмотрим, как их можно отключить еще на уровне прокси-сервера. Для этого сначала добавим в файл squid.conf следующие правила:

acl banners_regex url_regex "/usr/etc/banners_regex"

acl banners_path_regex urlpath_regex "/usr/etc/banners_j?ath_regex"

acl banners_exclusion url_regex "/usr/etc/banners_exclusion"

Первая строка создает ACL-список с именем banners_regex типа url_regex, который позволяет сравнивать полный URL-адрес. В последнем параметре определен файл /usr/etc/banners_regex, в котором будут указываться нужные адреса. Нас интересуют URL баннерных систем, и вы можете поместить их в этот файл.

Вторая строка создает ACL-список с именем banners_path_regex типа urlpath_regex. В последнем параметре снова указан файл /usr/etc/banners_path_regex, в котором вы должны описывать пути URL, которые впоследствии мы запретим.

Третья строка схожа с первой, но имеет имя banners_exclusion и связана с файлом /usr/etc/banners_exclusion. В первых двух файлах вы должны описывать пути или шаблоны, по которым потом будут обрезаться баннеры. Но бывают случаи, когда можно промахнуться и отсечь вполне полезную информацию. Если найден ошибочный путь, то его можно записать в этот файл, и баннер будет загружен.

Теперь добавляем еще две строки после описания ACL-записей:

http_access deny banners_path_regex !banners_exclusion

http_access deny banners_regex !banners_exclusion

Обе директивы имеют один и тот же смысл — запрещается загрузка по адресам, прописанным в списке banners_path_regex или banners_regex, если адрес не входит в исключение, описанное в файле ACL-списка banners_exclusion.

Рассмотрим фрагмент содержимого файла /usr/etc/banners_regex:

^http://members\.tripod\.com/adm/popup/.+html

^http://www\.geocities\.com/ad_container/pop\.html

Напоминаю, что в этом файле находятся URL-пути для сравнения, и все адреса, которые им соответствуют, будут отфильтрованы.

В первой строке описан шаблон, по которому запрещается загрузка адресов типа:

http://members.tripod.com/adm/popup/popup.html

Так просто. И пользователи больше не увидят всплывающие окна с сайта tripod.com. Если вы знакомы с регулярными выражениями, то сможете создать подобные записи для любой баннерной системы и обрезать самые замысловатые пути надоедливых картинок. Я не буду затрагивать регулярные выражения, потому что это тема достаточно большая и требует отдельной книги.

При борьбе с баннерами будьте готовы, что "обрезание" не всегда помогает, всплывающие окна могут снова появиться через определенное время. Это связано с тем, что баннеры — просто реклама, позволяющая зарабатывать деньги на существование сайта. Особо одаренные администраторы ищут любые возможные пути для того, чтобы ваша система не смогла избавиться от рекламы. Для этого постоянно изменяются адреса, чтобы регулярное выражение не сработало.

 

9.5.6. Подмена баннера

Пока что мы запретили загрузку баннеров или всплывающих окон. Но после этого Web-страницы перестанут быть привлекательными. Чтобы этого не произошло, можно заменять баннеры на свои картинки, которые хранятся на сервере, и отпадет необходимость грузить их из Интернета.

Для решения этой задачи очень хорошо подходит redirector. Для сервиса squid это внешняя программа, которая подменяет адреса. Например, если сайту необходимо загрузить баннер, и ваша программа смогла определить такую попытку, то redirector подменит адрес и вместо баннера загрузит то, что укажете вы.

Есть только одна проблема — в ОС нет и не может быть готовой программы. Ее необходимо написать. Для этого подойдет любой язык программирования, а я покажу вам пример, реализованный на языке Perl. Если вы умеете программировать на этом языке, то способ с redirector понравится вам больше, чем простой запрет через ACL.

Пример классической программы redirector можно увидеть в листинге 9.2. Я постарался максимально упростить его, чтобы вам легче было адаптировать сценарий под свои задачи.

Листинг 9.2. Сценарий на языке Perl для подмены баннеров и закрытия всплывающих окон

#!/usr/bin/perl

$| = 1;

# Укажите URL на вашем Web-сервере, где лежат картинки

$YOURSITE = 'http://yourserver.com/squid';

$LOG = '/usr/etc/redirectlog';

$LAZY_WRITE = 1;

if ($LOG) {

 open LOG, ">> $LOG";

 unless ($LAZY_WRITE) {

  select LOG;

  $|=1;

  select STDOUT;

 }

}

@b468_60 = qw (

 'www\.sitename\.com/cgi/

 # Добавьте сюда описания URL-адресов с баннерами

 # размером 468x60

);

@b100_100 = qw (

 www\.sitename\.com/cgi/

 # Добавьте сюда описания URL-адресов с баннерами

 # размером 100x100

);

@various = qw (

 www\.sitename\.com/cgi/

 # Добавьте сюда описания URL-адресов с нестандартными

 # размерами баннера

};

@popup_window = qw (

 ^http://members\.tripod\.com/adm/popup/.+html

 ^http://www\.geocities\.com/ad_container/pop\.html

 ^http://www\.geocities\.com/toto\?

 # Добавьте сюда описания URL-адресов, с которых

 # выскакивают всплывающие окна

);

# Описание расположения картинок

$b468_60 = "$YOURSITE/468_60.gif";

$b100_100 = "$YOURSITE/100_100.gif";

$various = "$YOURSITE/empty.gif";

$closewindow = "$YOURSITE/close.htm";

while (<>) {

 ($url, $who, $ident, $method) = /^(\S+) (\S+) (\S+) (\S+)$/;

 $prev = $url;

 # Проверка баннера 468x60

 $url = $b468_60 if grep $url =~ m%$_%, @b468_60;

 # Проверка баннера 100x100

 $url = $b100_100 if grep $url =~ m%$_%, @bl00_100;

 # Проверка баннера произвольного размера

 $url = $various if grep $url =~ m%$_%, @various;

 # Всплывающее окно

 $url = $closewindow if grep $url =~ m%$_%, @popup_window;

 # Отдельный сайт, не внесенный в список в начале файла

 $url = "$YOURSITE/empty.gif" if $url =~ m%hitbox\.com/Hitbox\?;

 if ($LOG and $url ne $prev) {

  my ($sec, $min, $hour, $mday, $mon, $year) = localtime;

  printf LOG "%2d.%02d.%2d %2d:%02d:%04d: %s\r\n",

   $mday, $mon + 1, $year + 1900, $hour, $min, $sec,

   "$who $prev > $url";

 }

 print "$url $who $ident $method\n";

}

close LOG if $LOG;

Сохраните эту программу в файле /usr/etc/redirector и установите для squid права на его исполнение. После этого добавьте в файл squid.conf следующую строку:

redirect_program /usr/local/etc/squid/redirector

Чтобы эта программа заработала, создайте на своем Web-сервере файлы со следующими именами:

□ 468_60.gif — картинка размером 468×60;

□ 100_100.gif — картинка размером 100×100;

□ empty.gif — картинка, которая будет заменять нестандартные баннеры. Лучше всего ее сделать размером 1×1 пиксель, чтобы она не испортила дизайн сайта;

□ close.htm — HTML-файл, который будет закрывать всплывающие окна. В нем нужно поместить всего лишь функцию, которая будет закрывать окно. Для этого используется JavaScript-функция window.close(). Пример содержимого файла показан в листинге 9.3.

Все эти файлы должны лежать на Web-сервере в одной директории. Не забудьте в сценарии (в переменной $YOURSITE) указать правильный путь к этому каталогу.

Я постарался снабдить код в листинге 9.2 комментариями. Если у вас есть опыт программирования на Perl, то дальнейшие действия вы выполните без проблем.

Листинг 9.3. Пример JavaScript-файла, закрывающего всплывающее окно

 

 

 

 

 

 

9.5.7. Борьба с запрещенными сайтами

Недавно я разговаривал с одним своим знакомым, и мне понравилось его определение Интернета — сеть создана и живет порнографией. Я не уверен, но мне кажется, что он прав в том, что трафик с сайтов с интим-содержимым самый высокий (если не считать службу обновления Microsoft, где пользователи скачивают патчи для программ этой компании :)).

Ни один работодатель не обрадуется, если его сотрудники в рабочее время будут посещать сайты с запрещенным контентом (это не только бесполезная трата трафика, но и другие непроизводительные расходы). Родители тоже не хотят, чтобы их дети рассматривали подобные сайты, поэтому стремятся оградить их от этого зрелища. Это я говорю уже как отец двоих детей.

Порно-сайты легко можно запретить с помощью таких же методов, как мы использовали для баннеров. Например, можно отключить любые сайты, в адресе которых есть слово "sex". Но нельзя забывать, что могут быть исключения. К примеру, адрес может содержать текст "GasExpo". Обратите внимание, что выделенные буквы создают слово "sex". А ведь это реальный случай из жизни, когда пользователь сети не смог попасть на сайт выставки по газовому оборудованию.

Создавать списки запрещенных сайтов достаточно сложно, но можно. В настоящее время в зоне com большинство сайтов эротической направленности закрылись и обживают другие места, которые принадлежат маленьким государствам. Существуют домены, которые на 90% состоят из сайтов индустрии развлечений для взрослых. Вот их можно исключить полностью.

 

9.5.8. Ограничение канала

При организации доступа в Интернет очень часто требуется отдельным пользователям обеспечить большую скорость подключения. Как это сделать, когда по умолчанию все равноправны и могут работать на максимально доступной на данный момент скорости? Для этого нужно определиться с приоритетами. Для некоторых пользователей должен быть зарезервирован высокоскоростной канал связи. Нельзя повысить скорость одному человеку без ущерба остальным.

Если кому-то требуется полоса гарантированной пропускной способности для работы с приложениями, требующими высокой скорости обмена (например, для проведения презентаций), вы должны зарезервировать для них более мощный, чем для остальных канал.

Ограничение внешнего канала достаточно легко выполнить с помощью squid, Директивы, которые нужно использовать, можно увидеть в следующем примере:

delay_pools 3

delay_class 1 1

delay_class 2 2

delay_class 3 1

delay_parameters 1 256000/256000

delay_access 1 deny all

delay_access 1 allow admins

delay_parameters 2 256000/256000 4000/8000

delay_access 2 allow all

delay_access 2 deny admins

delay_parameters 3 64000/64000

delay_access 3 deny all

delay_access 3 allow bigboss

Этот код нужно добавить в файл конфигурации /etc/squid/squid.conf после комментария:

# DELAY POOL PARAMETERS (all require DELAY_POOLS compilation option)

#-------------------------------------------------------------------

Большинство параметров уже заданы по умолчанию, и их следует заменить.

Давайте подробно рассмотрим конфигурацию. Для начала нужно определить, сколько у вас будет пулов (правил, описывающих скорость доступа). Для этого используется директива delay_pools n, где n — это количество пулов. По умолчанию n равно нулю, и нет никаких ограничений. Мы создадим три пула, поэтому в примере указано число 3.

После этого нужно определить, к какому классу относится пул. Это делается с помощью директивы delay_class n c, где n — это порядковый номер, а c — номер класса. Каждая строка с директивой delay_class должна иметь свой порядковый номер, который начинается с 1. В нашем примере две строки, поэтому в первой параметр n равен 1, а во второй — 2.

Номеров класса (второй параметр) может быть три:

□ 1 — ограничение канала происходит для всей сети. Например, у вас внешний канал 256 Кбит/с, вы можете его уменьшить для всех до 64 Кбит/с;

□ 2 — сузить можно общий канал и помимо этого для каждого пользователя индивидуально. В этом случае общий канал может быть понижен до 64 Кбит/с, и каждый пользователь в отдельности сможет работать только на скорости 4 Кбит/с;

□ 3 — ограничивать можно общий канал, индивидуально и для каждой сети в отдельности. Например, если скорость канала равна 256 Кбит/с, а в вашей сети работает 4 подсети, то каждой из них можно выделить по 64 Кбит/с, чтобы равномерно разделить нагрузку.

В нашем примере мы используем пулы 1 и 2 и снова 1 класса. Я специально расположил их не последовательно, чтобы пример был более наглядным.

Теперь описываем параметры скорости доступа. Это делается с помощью следующей директивы:

delay_parameters пул скорость_канала скорость_сети индивидуально

пул — это номер пула, скорость которого мы хотим описать. Так, в нашем примере следующая строка описывает скорость для первого пула:

delay_parameters 1 256000/256000

Так как пул 1 имеет 1 класс (delay_class 1 1), у которого можно ограничивать только канал полностью, в директиве используется единственный параметр — скорость_канала (256000/256000). Он формируется в виде двух чисел, разделенных знаком "/". До слэша указывается скорость, с которой будут скачиваться данные из сети, а после — размер пула, т.е. емкость, которую можно наполнить полученными из сети данными.

Количество параметров зависит от класса используемого пула. Если вы используете 1 класс, где можно ограничивать только общий канал, то должны быть указаны только два параметра:

delay_parameters пул скорость_канала

Если используется второй класс, то директива выглядит следующим образом:

delay_parameters пул скорость_канала индивидуально

Итак, первая директива использует полную скорость канала 256 000 байт в секунду. Обратите внимание, что скорость указывается именно в байтах, а характеристика модема задается в битах в секунду. Если в качестве скорости указать значение -1, то никаких ограничений не будет.

После определения параметров для первого пула нужно установить права доступа к нему. Это делается директивой delay_access, которая имеет следующий вид:

delay_access пул доступ acl

Первый параметр — это снова номер пула. Потом указывается доступ allow или deny, и последним идет имя списка.

В нашем примере для первого пула используется две строки:

delay_access 1 deny all

delay_access 1 allow admins

Сначала мы запрещаем доступ для всех, а потом разрешаем работать на данной скорости только ACL-списку admins. Подразумевается, что в этот список входят администраторы.

Далее идет описание скорости и прав доступа для второго пула:

delay_parameters 2 256000/256000 4000/8000

delay_access 2 allow all

delay_access 2 deny admins

Так как второй пул относится ко 2 классу, то здесь нужно указать общую скорость (256 000 байт в секунду) и скорость доступа каждого компьютера в отдельности — 4000 байт в секунду. На такой скорости будут работать все пользователи в сети, кроме администраторов.

Если вы установите такие правила в какой-либо организации, то могут возникнуть проблемы с руководством, потому что директор тоже попадет в список all и будет работать на скорости 4000 байт в секунду. Я думаю, что его это не устроит, и для него мы сделаем отдельную запись:

delay_parameters 3 64000/64000

delay_access 3 deny all

delay_access 3 allow bigboss

С помощью ограничения пропускной способности канала можно запретить загрузку мультимедийных файлов в рабочее время. В следующем примере мы разрешаем быстро читать Web-странички, но уменьшаем скорость загрузки других медиафайлов (листинг 9.4).

Листинг 9.4. Ограничение скорости загрузки медиафайлов в рабочее время

# ACL-список, описывающий сеть

acl fullspeed url_regex -i 192.168.1

# ACL-список, описывающий медиафайлы, для которых необходимо

# понизить скорость

acl mediaspeed url_regex -i ftp .exe .mp3 .avi .mpeg .iso .wav

# Время, которое будет действовать ограничение на скорость

# загрузки медиафайлов

acl day time 08:00-18:59

# Нам нужно два пула второго класса

delay_pools 2

delay_class 1 2

delay_class 2 2

# Первый пул не имеет ограничений для всех

delay_parameters 1 -1/-1 -1/-1

delay_access 1 allow fullspeed

# Второй пул ограничивает доступ в дневное время

delay_parameters 2 4000/100000 4000/100000

delay_access 2 allow day

delay_access 2 deny !day

delay_access 2 allow mediaspeed

Я постарался снабдить листинг подробными комментариями, чтобы вы могли с ним разобраться без дополнительных пояснений. Хочу только заметить, что скорость понижается для всех. Если вы хотите разрешить определенным пользователям работать на полной скорости, можно внести их в список (например, allowfull) и добавить в конец листинга следующую строку:

delay_access 2 deny !allowfull