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, не выйдет.
9.5. Замечания по работе squid
Сейчас нам предстоит немного поговорить о некоторых вопросах безопасности сервиса 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.
