Linux глазами хакера - Михаил Флёнов

□ 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 (установлено по умолчанию).

9.4. Права доступа к squid

Это самая больная тема для любого администратора. Да, и в 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.

acl all src 0.0.0.0/0.0.0.0