Как создать и настроить прокси-сервер Squid
Оглавление
3. Как установить Squid в Linux
5. Конфигурационный файл Squid
7. Как скрыть, что используется прокси-сервер Squid
8. Настройка подключения к прокси-серверу Squid по логину и паролю
8.1 Как настроить HTTP Basic аутентификацию в Squid
8.2 Как настроить HTTP Digest аутентификацию в Squid
9. Как отключить кэширование в Squid
10. Как блокировать сайты на прокси-сервере Squid
12. Как настроить Squid использовать различные IP адреса
13. Как заставить Squid использовать IPv4, а не IPv6
14. Как добавлять, изменять и удалять HTTP заголовки в Squid
15. Вопросы и ответы по настройки и использованию Squid. Примеры конфигураций Squid
15.1 Как настроить веб-браузер (или Windows) для работы через прокси
15.2 Разрешение доступа на определённые сайты по паролю
15.3 Как в URL блокировать определённые ключевые слова с помощью Squid
15.4 Конфигурация Squid для различных пользователей
15.5 Запуск Squid без перевода в фон
15.6 Как заблокировать все адреса назначения кроме одного
15.7 Как только одному адресу разрешить доступ к определённому URL
15.8 Почему в Squid рекомендуется блокировать некоторые порты
15.9 Как посмотреть, какие IP адреса прослушивает прокси-сервер Squid
15.10 Как сделать так, чтобы прокси-сервер Squid прослушивал только локальный порт
15.11 Почему Squid открывает UDP порты
15.12 Как настроить кэширование в прокси-сервере Squid
15.13 Поддерживает ли Squid SOCKS4 или SOCKS5
15.14 Директивы из минимальной рекомендуемой конфигурации
15.15 Как настроить работы прокси Squid с множеством пользователей
15.16 Настройка Squid для работы с OpenVPN
15.17 Как отредактировать страничку блокировки в Squid? Вставить свои картинки и почту
15.18 Как установить e-mail менеджера кэша Squid
16. Возможные ошибки и проблемы при использовании прокси-сервера
16.1 Ошибка «Прокси-сервер отказывается принимать соединения»
16.2 Squid может открыть сайты по HTTP протоколу, но не может открыть HTTPS
Прокси-сервер Squid
В этой инструкции мы познакомимся с основами настройки Squid, то есть сможем поднять свой собственный прокси-сервер на своём сервере, научимся настраивать прокси-сервер Squid для работы с несколькими IP адресами, настроим различные способы аутентификации клиентов, узнаем нюансы функционирования Squid, которые могут иметь отношение к анонимности.
Прокси-сервер — это компьютер, который используется в качестве посредника между клиентом и другими серверами, с которого клиент может запрашивать ресурсы. Простой пример этого:
- когда клиент делает онлайн-запросы (например, хочет открыть веб-страницу), он сначала подключается к прокси-серверу;
- затем прокси-сервер проверяет свой локальный дисковый кеш, и, если данные могут быть найдены там, он вернёт данные клиенту
- а если они ещё не кэшированы, он сделает запрос от имени клиента, используя IP-адрес прокси (отличный от клиентского), а затем вернёт данные клиенту;
- прокси-сервер попытается кэшировать новые данные и будет использовать их для будущих запросов к тому же серверу.
Смотрите также: Всё о прокси: виды, как пользоваться, как проверить качество прокси
Веб-прокси существуют уже довольно давно и используются миллионами людей по всему миру. У них широкий спектр целей, наиболее популярной из которых является онлайн-анонимность, но есть и другие способы использования веб-прокси. Вот несколько идей:
- Анонимность в сети
- Повышение онлайн-безопасности
- Уменьшить время загрузки
- Блокировать вредоносный трафик
- Вести учёт своей онлайн-активности
- Чтобы обойти региональные ограничения
- В некоторых случаях может снизить использование полосы пропускания (нагрузку на сеть)
- Ограничение доступа к определённым ресурсам с гибкой возможностью настройки: введение ограничений только для определённых пользователей, по расписанию, с требованием аутентификации и так далее
Squid — это самый популярный веб (HTTP) прокси-сервер с кэшированием и перенаправлением (форвардинг), его главное применение это сокрытие IP адреса пользователей, а также кэширования веб-страниц с веб-сервера, чтобы повысить скорость веб-сервера, уменьшить время отклика и уменьшить использование полосы пропускания сети.
Команды установки Squid различаются на разных Linux, но последующая настройка одинакова во всех дистрибутивах. В этой статье мы будем использовать Squid в качестве HTTP/HTTPS прокси-сервера без кэширования.
В этой статье мы объясним, как установить прокси-сервер squid в дистрибутивах Linux и в Windows и использовать его в качестве HTTP/HTTPS прокси-сервера.
Выбрать Squid или 3proxy?
Если для вас не важна такая функциональность как кэширование, а важно в первую очередь скрывать IP адрес или делать запросы с множества IP адресов, то функциональность Squid и 3proxy схожа в этом плане. Прокси-сервер 3proxy и создавался как замена Squid. На самом деле изначально эта инструкция задумывалась про 3proxy, но я не сумел запустить его: потратив несколько бесплодных часов я сдался и прекратил попытки запустить службу, которая просто завершает свою работу не выводя никаких сообщений ни в stderr, ни в системный журнал, ни в какой-либо файл. Да, я читал мануалы, читал официальную документацию на сайте, даже гуглил инструкции — не заработало…
С Squid всё получилось довольно быстро, поэтому сейчас вы читаете про прокси-сервер Squid.
Но 3proxy это тоже популярный прокси-сервер и я обязательно доразберусь с ним и ему будет посвящена отдельная статья. Что-то мне подсказывает, что не смотря на обилие документации на официальном сайте, не мне одному нужна рабочая и понятная инструкция по работе с 3proxy и его настройке ))
Как установить Squid в Linux
Как установить Squid на Debian, Linux Mint, Ubuntu, Kali Linux
Пакет Squid доступен для установки из базового репозитория этих дистрибутивов, но перед этим обязательно обновите кэш пакетов, запустив:
sudo apt update
После обновления информации о пакетах, вы можете продолжить установку squid:
sudo apt -y install squid
Установка Squid в Arch Linux, Manjaro и их производные
Выполните обновление кэша информации об установочных пакетах и саму установку следующей командой:
sudo pacman -Sy squid
Установка Squid в CentOS
Обновляем информацию о пакетах:
yum -y update
Устанавливаем прокси-сервер:
yum -y install squid
Запуск и добавление Squid в автозагрузку
Следующие команды одинаковы во всех дистрибутивах Linux для запуска Squid.
Чтобы запустить прокси-сервер выполните:
sudo systemctl start squid
На этом этапе ваш веб-прокси Squid уже должен быть запущен, и вы можете проверить статус службы с помощью:
systemctl status squid
Пример вывода:
Для добавления службы Squid в автозагрузку выполните команду:
sudo systemctl enable squid
Далее мы будем вносить изменения в конфигурационный файл прокси-сервера, чтобы они вступили в силу выполните:
sudo systemctl restart squid
Для остановки и удаления службы прокси-сервера из автозагрузки используйте команды:
sudo systemctl stop squid sudo systemctl disable squid
Установка Squid в Windows
Squid может компилироваться и запускаться в Windows как системная служба с использованием среды эмуляции Cygwin или может быть скомпилирован в собственном режиме Windows с использованием среды разработки MinGW + MSYS. Поддерживаются Windows NT 4 SP4 и более поздние версии.
Известные ограничения
- Функции Squid, которые не работают в Windows:
- DISKD: ещё нужно портировать
- Прозрачный прокси: отсутствует некоммерческий драйвер перехвата для Windows
- WCCP: эти функции не были перенесены. Без поддержки прозрачного прокси в этом нет необходимости.
- Поддержка SMP: Windows-эквивалент сокетов UDS не реализован
- Некоторые разделы кода могут совершать блокирующие вызовы.
- Некоторые внешние помощники могут не работать.
- Количество файловых дескрипторов жёстко ограничено до 2048 при сборке с помощью MinGW.
- Squid-3.x всех официальных выпусков имеет серьёзные проблемы со сборкой.
Предварительно созданные двоичные пакеты Squid для Windows
Это самый простой способ получить Squid в Windows — проект с открытым исходным кодом https://github.com/diladele/squid-windows предоставляет файлы установщика MSI Windows для Squid Proxy Server. Он делает возможным установку Squid буквально в несколько кликов. Текущая сборка основана на последней сборки Squid 4.14 для Cygwin под Windows 64 bit.
Для скачивания установщика перейдите на сайт: https://squid.diladele.com/ и нажмите ссылку «MSI installer for SQUID FOR WINDOWS».
Запустите скаченный файл двойным кликом и следуйте подсказкам установщика.
Сразу после завершения работы установщика, рядом с часами появится иконка для управления службой Squid:
При клике на неё будут доступны следующие опции:
- Open Squid Configuration – Открыть файл настроек
- Open Squid Folder – Открыть папку программы
- Start Squid Service – Запустить службу Squid (неактивна, если служба уже запущена)
- Stop Squid Service – Остановить службу Squid
- About – О
- Exit – Выйти
Путь до конфигурационного файла в Windows: C:\Squid\etc\squid\squid.conf. Имейте это ввиду, так как во всех последующих разделах настройка будет показана на примере Linux.
Чтобы сделанные в конфигурационном файле изменения вступили в силу, нужно перезапустить службу Squid, для этого остановите и запустите её снова.
Служба Squid будет автоматически запускаться при включении компьютера, а чтобы появилась иконка в трее для управления Squid нужно запустить файл C:\Squid\bin\Diladele.Squid.Tray.exe.
В конфигурационном файле вы можете увидеть пути вроде такого: «/cygdrive/d/squid/cache». Чтобы их понимать, посмотрите «Как получить доступ к дискам в Cygwin». В данном случае /cygdrive/d/squid/cache это D:\squid\cache.
Также там будут пути вроде такого: /var/cache/squid — это всё директории внутри папки C:\Squid. То есть, например, /var/cache/squid — это на самом деле C:\Squid\var\cache\squid\.
Чтобы проверить, действительно ли служба Squid прослушивает порт для подключения, вы можете выполнить следующее:
1. Нажмите Win+x и в открывшемся меню выберите «Windows PowerShell (администратор)».
2. Последовательно выполните команды:
cmd for /f "tokens=1,2,3,4,5*" %i in ('netstat -aon ^| findstr ":3128" ^| findstr /i listening') do echo %j %l & @tasklist | findstr %m
Вы убедитесь, что Squid действительно прослушивает порт 3128.
Помните, что если вы используете файервол, то вам нужно открыть порт, который прослушивает служба прокси-сервера, если вы его не меняли, то по умолчанию это 3128.
Далее выполнение всех действий показано на примере Linux, поскольку Squid намного сильнее распространён именно на Linux, а не на Windows. Тем не менее, вы, пользователи Windows, можете использовать последующую информацию для настройки Squid на Windows. Но вам нужно иметь ввиду следующие нюансы:
1. Когда приводится команда на открытие файла, вы должны открывать свой конфигурационный файл, путь до которого дан чуть выше.
2. Когда говориться, что нужно перезапустить службу и даётся для этого команда, вам нужно открыть помощник в трее и остановить, а потом запустить службу там.
Если вы продвинутый пользователь, то можете управлять службой в командной строке (открытой с правами администратора):
net stop squidsrv net start squidsrv
Смотрите также: Как управлять службами в Windows
Для управления автозапуском службы, смотрите статью «Как отключить автозапуск программ и служб в Windows».
3. Скорее всего (я не проверял) вы не сможете настроить авторизацию по логину и паролю на прокси-сервере, так как многие (или все) помощники не работают в Windows.
4. В конфигурационном файле пути до файлов в Linux и Windows могут совпадать, так как Cygwin эмулирует рабочее окружение Linux, но перепроверяйте.
Конфигурационный файл Squid
Ниже приведены некоторые важные местоположения файлов Squid, о которых вам следует знать:
- Файл конфигурации Squid: /etc/squid/squid.conf
- Журнал доступа к Squid: /var/log/squid/access.log
- Журнал кэша Squid: /var/log/squid/cache.log
По умолчанию конфигурационный файл Squid не пустой — его содержимое различается в зависимости от дистрибутива Linux и в любом случае в нём довольно много директив с настройками. Не спешите их удалять — прокси-сервер Squid устроен так, что если подключение не разрешено явно в его настройках, то он отклоняет все подключения.
В дистрибутивах на основе Debian (Kali Linux, Linux Mint, Ubuntu) в файле /etc/squid/squid.conf содержится полная документация (8500 строк) среди которой есть вкрапления настроек — незакомментированные строки начинаются после 1200+ строки). В дистрибутивах на основе Arch Linux в файле /etc/squid/squid.conf содержится только рекомендуемая минимальная конфигурация, которая приведена ниже.
С помощью следующей команды вы можете посмотреть, какие директивы по умолчанию включены в Debian:
grep -Eiv '(^#|^$)' /etc/squid/squid.conf
Кратко ознакомимся с содержимым конфигурационного файла по его комментариях.
# # Рекомендуемая минимальная конфигурация: # # Пример правила, позволяющего доступ из вашей локальной сети. # Адаптируйте этот список под свои нужды, указывая (внутренние) IP # сетей откуда должен быть разрешён вход acl localnet src 0.0.0.1-0.255.255.255 # RFC 1122 "this" network (LAN) acl localnet src 10.0.0.0/8 # RFC 1918 local private network (LAN) acl localnet src 100.64.0.0/10 # RFC 6598 shared address space (CGN) acl localnet src 169.254.0.0/16 # RFC 3927 link-local (directly plugged) machines acl localnet src 172.16.0.0/12 # RFC 1918 local private network (LAN) acl localnet src 192.168.0.0/16 # RFC 1918 local private network (LAN) acl localnet src fc00::/7 # RFC 4193 local private network range acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines # Итак, в предыдущей секции мы создали правило доступа с именем localnet. # Создаём ещё одно правила с именами SSL_ports и SSL_ports и перечисляем в нём порты acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https 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 # # Рекомендуемая минимальная конфигурация разрешения доступа: # # Теперь мы запрещаем доступ ко всем портам, кроме добавленных в правило Safe_ports http_access deny !Safe_ports # Запрещаем CONNECT для всех портов, кроме перечисленных в правиле SSL_ports http_access deny CONNECT !SSL_ports # Разрешаем доступ к cachemgr только от localhost http_access allow localhost manager http_access deny manager # Мы настоятельно рекомендуем раскомментировать следующее, чтобы защитить невинные веб-приложения, # работающие на прокси-сервере, которые думают, что единственный, кто может получить доступ # к службам на "localhost", - это локальный пользователь. #http_access deny to_localhost # # ВСТАВЬТЕ СВОИ СОБСТВЕННЫЕ ПРАВИЛА, ЧТОБЫ РАЗРЕШИТЬ ДОСТУП ДЛЯ ВАШИХ КЛИЕНТОВ # # Далее мы настраиваем доступ, разрешая его всем, кто перечислен в правиле с именем localnet, а также localhost (локальному хосту): http_access allow localnet http_access allow localhost # Наконец, мы запрещаем доступ всем другим к этому прокси http_access deny all # Squid по умолчанию прослушивает порт 3128 http_port 3128 # Раскомментируйте и настройте следующее, чтобы добавить каталог дискового кэша. #cache_dir ufs /var/cache/squid 100 16 256 # Оставьте coredumps в первом каталоге кеша coredump_dir /var/cache/squid # # Добавьте над ними любую из ваших собственных записей refresh_pattern. # refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320
ИМХО, удобнее делать настройку с нуля, особенно если у вас в этом файле целиком помещена документация. Поэтому сделаем резервную копию конфигурационного файла:
mv /etc/squid/squid.conf /etc/squid/squid.conf.bac
А в дальнейшем будем записывать конфигурационные директивы в новый пустой файл.
Настройка Squid в качестве HTTP-прокси в Linux. Как разрешить подключаться к прокси только определённым IP
Рассмотрим как настроить squid в качестве прокси-сервера HTTP, используя только IP-адрес клиента для аутентификации. То есть мы пока не будем устанавливать логин и пароль для доступа к прокси-серверу, но мы запретим к нему доступ всем, кроме указанного IP адреса.
Добавление ACL Squid
Если вы хотите разрешить доступ в Интернет только одному IP-адресу через ваш новый прокси-сервер, вам нужно будет установить новый acl (access control list, то есть список контроля доступа) в файле конфигурации. Более подробно об ACL будет далее.
sudo vim /etc/squid/squid.conf
Вам следует добавить следующее правило acl:
acl localnet src XX.XX.XX.XX http_access allow localnet http_port ПОРТ
Где:
- XX.XX.XX.XX — IP-адрес клиентской машины для которой разрешено подключение. Этот ACL следует добавить в начало раздела ACL, как показано на следующем снимке экрана
- ПОРТ — порт, к которому будет подключаться клиентская машина
- имя «localnet» используется только потому, что в конфигурации по умолчанию уже есть данный список и для него уже установлено правило «разрешить». На самом деле, можно выбрать любое другое имя, которое будет отражать содержимое списка, например «allowed_hosts»
Вы могли видеть примеры правил acl выше.
Всегда рекомендуется оставлять комментарий рядом с ACL, который будет описывать, например, кто использует этот IP-адрес.
acl localnet src 192.168.0.102 # IP-адрес босса
Пример минимальной конфигурации, когда к прокси-серверу разрешено подключение только с IP адреса 185.117.153.79, в качестве порта прокси-сервера используется 4080:
acl localnet src 185.117.153.79 http_access allow localnet http_port 4080
Вам нужно будет перезапустить сервис Squid, чтобы новые изменения вступили в силу.
sudo systemctl restart squid
С помощью веб-браузера проверим подключение к прокси-серверу.
В первую попытку сделано подключение НЕ с 185.117.153.79 (единственный разрешённый IP адрес):
Мы получили ожидаемую ошибку:
Прокси-сервер отказывается принимать соединения Firefox настроен на использование прокси-сервера, который отказывает в соединении. Проверьте настройки прокси-сервера и убедитесь, что они верны. Свяжитесь с вашим системным администратором и убедитесь, что прокси-сервер работает.
После того, как я поменял свой IP адрес на 185.117.153.79 (единственный разрешённый IP адрес), подключение прошло нормально.
Посмотрим на журнал подключений прокси-сервера:
cat /var/log/squid/access.log
Как вы можете увидеть, все запросы с IP адреса 84.53.229.35 имеют статус «TCP_DENIED/403», то есть отклонены. А запросы с разрешённого IP адреса 185.117.153.79 имеют статус «TCP_TUNNEL/200» и «TCP_MISS/200».
Посмотрим на свой IP: https://suip.biz/ru/?act=myip
Показан IPv6 адрес моего прокси-сервера.
Как скрыть, что используется прокси-сервер Squid
Зайдём на сервис выявления прокси-сервера: http://suip.biz:8080/ru/?act=proxy-checker
И прокси-сервер успешно обнаружен, меня выдал HTTP заголовок:
Via: 1.1 w-e-b (squid/4.13)
RFC2616 требует, чтобы прокси-сервера добавляли этот заголовок в запрос и ответ. Прокси-сервер Squid может быть скомпилирован с поддержкой нарушения HTTP стандартов. Ранее для этого требовалось при компиляции указать опцию —enable-http-violations, а теперь поддержка нарушения стандартов включена по умолчанию (для её отключения нужно скомпилировать с опцией —disable-http-violations). Вы можете добавить в файл настроек следующую директиву, в результате чего HTTP заголовок Via не будет добавляться:
via off
Заголовок X-Forwarded-For не требуется стандартами и по умолчанию отключён, тем не менее, для большей уверенности вы можете отключить его явно:
forwarded_for off
Тег forwarded_for может иметь одно из следующих значений:
- on
- off
- transparent
- truncate
- delete
Если установлено значение «on», Squid будет добавлять IP-адрес вашего клиента в HTTP-запросы, которые он пересылает. По умолчанию это выглядит так:
X-Forwarded-For: 192.1.2.3
Если установлено значение «off», Он будет отображаться как
X-Forwarded-For: unknown
Если установлено значение «transparent», Squid никоим образом не изменит заголовок X-Forwarded-For.
Если установлено значение «delete», Squid удалит весь заголовок X-Forwarded-For.
Если установлено значение «truncate», Squid удалит все существующие записи X-Forwarded-For и поместит IP-адрес клиента в качестве единственной записи.
После добавления «via off» и перезапуска прокси-сервера, этот HTTP заголовок исчез.
Но не удалось перехитрить сервисы, по поиску утечек:
Они смогли определить, что используется прокси по следующим признакам:
- Открытые порты web proxy
- Разница во временных зонах (браузера и IP)
- Принадлежность IP хостинг провайдеру
- Определение туннеля (двусторонний пинг)
Но настоящий IP пользователя за прокси они узнать не смогли.
Обратите внимание, что выполнять какие-либо манипуляции с трафиком, в том числе с HTTP заголовками, прокси сервер может только если веб-сайт работает на протоколе HTTP, при использовании протокола HTTPS, любые изменения передаваемых данных невозможны, поскольку трафик зашифрован. То есть при обращении к сайтам на HTTPS протоколе заголовок Via не добавляется в любом случае.
Настройка подключения к прокси-серверу Squid по логину и паролю
Как настроить HTTP Basic аутентификацию в Squid
Чтобы разрешить пользователям аутентифицироваться перед использованием прокси, вам необходимо включить базовую HTTP-аутентификацию в файле конфигурации, но перед этим вам необходимо установить пакет, содержащий утилиту htpasswd.
В Debian и производных это пакет apache2-utils, для его установки используйте следующую команду.
sudo apt install apache2-utils
В Arch Linux и производных данная утилита содержится в пакете apache:
sudo pacman -S apache
В CentOS нужный пакет называется httpd-tools, установите его:
yum -y install httpd-tools
Теперь мы создадим запись для пользователя с именем «mial» и установим его пароль.
sudo htpasswd -c /etc/squid/passwd mial
Вывод:
New password: Re-type new password: Adding password for user mial
Опция -c в предыдущей команде нужна для создания нового файла (или перезаписи существующего), если вы хотите модифицировать файл (изменить пароль для одного из пользователей или создать новую запись для другого пользователя), запускайте команду без этой опции:
sudo htpasswd /etc/squid/passwd ПОЛЬЗОВАТЕЛЬ
Теперь, чтобы включить базовую HTTP-аутентификацию, откройте файл конфигурации.
sudo vim /etc/squid/squid.conf
Можно сочетать аутентификацию по IP адресу и по паролю, либо можно настроить аутентификацию по паролю разрешив доступ с любого IP, я выбираю второй вариант, то есть кто угодно, зная пароль, может использовать прокси-сервер. Поэтому я удаляю из конфигурационного файла строки:
acl localnet src 185.117.153.79 http_access allow localnet
После списков ACL (если они есть) добавьте следующие строки:
auth_param basic program /usr/lib64/squid/basic_ncsa_auth /etc/squid/passwd auth_param basic children 5 auth_param basic credentialsttl 2 hours auth_param basic casesensitive on auth_param basic realm Squid proxy for HackWare.ru acl auth_users proxy_auth REQUIRED http_access allow auth_users
Несколько пояснений по данным директивам:
- Нам нужно указать Squid, какую вспомогательную программу аутентификации использовать с директивой auth_param, указав имя программы (скорее всего, /usr/lib/squid/ncsa_auth или /usr/lib64/squid/basic_nsca_auth), а также, если необходимо, любые параметры командной строки (в данном случае /etc/squid/passwd).
- Файл /etc/squid/passwd создаётся с помощью htpasswd, инструмента для управления базовой аутентификацией через файлы. Это позволит нам добавить список имён пользователей (и соответствующих им паролей), которым будет разрешено использовать Squid.
- credentialsttl 2 hours означает, что пользователю нужно будет вводить пароль каждые два часа (вы также можете указать этот временной интервал с минутами, используя слово «minutes»).
- casesensitive on указывает, что имена пользователей и пароли чувствительны к регистру.
- realm представляет собой текст диалога аутентификации, который будет показан пользователю в окне аутентификации в squid.
- children 5 определяет максимальное количество запускаемых процессов аутентификатора. Если вы запустите их слишком мало Squid, другим пользователям придётся ждать, пока до них дойдёт очередь и они смогут выполнить аутентификацию, что замедлит процесс. Когда проверка пароля выполняется через (медленную) сеть, вам, вероятно, понадобится много процессов аутентификации. С другой стороны — ограничение количества одновременных проверок логина и пароля позволит сильно замедлить брут-форс (подбор пароля) для вашего прокси-сервера
- Наконец, доступ к прокси предоставляется только при успешной аутентификации (proxy_auth REQUIRED).
Обратите внимание, что в различных дистрибутивах Linux путь до файла basic_ncsa_auth может чуть различаться:
- /usr/lib64/squid/basic_ncsa_auth (Arch Linux, CentOS)
- /usr/lib/squid/basic_ncsa_auth (Debian, Linux Mint, Ubuntu, Kali Linux)
В некоторых системах файл расположен в обоих директориях (Arch Linux).
Вы можете проверить, где именно в вашей системе расположен файл:
ls -l /usr/lib64/squid/basic_ncsa_auth ls -l /usr/lib/squid/basic_ncsa_auth
На сервере, который я настраиваю путь до файла /usr/lib/squid/basic_ncsa_auth и прокси сервер использует порт 4080, тогда конфигурация следующая:
http_port 4080 via off auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd auth_param basic children 5 auth_param basic credentialsttl 2 hours auth_param basic casesensitive on auth_param basic realm Squid proxy for HackWare.ru acl auth_users proxy_auth REQUIRED http_access allow auth_users
Сохраните файл и перезапустите squid, чтобы новые изменения вступили в силу:
sudo systemctl restart squid
Попробуем открыть веб-сайт в веб-браузере, использующем наш прокси:
После ввода имени пользователя и пароля мы можем просматривать сайты через прокси.
Посмотрим журнал /var/log/squid/access.log:
Можно увидеть, что вначале статус TCP_DENIED, то есть запрос отклонён, но после ввода логина и пароля прокси стал принимать запросы. Также обратите внимание, что теперь запросы принимаются независимо от IP адреса пользователя.
Как настроить HTTP Digest аутентификацию в Squid
Basic аутентификация плоха тем, что пароль передаётся фактически в виде простого текста (кодирован в Base64). Подробности смотрите в статье «Атаки на HTTP Basic и Digest аутентификацию».
Поэтому предпочтительнее использовать Digest аутентификацию на проксе сервере Squid.
Начнём с создания файла с хешем пароля, это делается командой вида:
sudo htdigest -c /etc/squid/passwd_digest REALM ПОЛЬЗОВАТЕЛЬ
REALM — это область применения. В качестве REALM может быть любая строка, но помните, что эта же самая строка впоследствии будет показана в форме ввода имени пользователя и пароля.
Пример команды создающей файл с хешем пароля для пользователя mial:
sudo htdigest -c /etc/squid/passwd_digest 'Squid proxy for HackWare.ru' mial
Пример конфигурационного файла для HTTP Digest аутентификация в Squid:
http_port 4080 via off cache deny all auth_param digest program /usr/lib/squid/digest_file_auth -c /etc/squid/passwd_digest auth_param digest children 5 auth_param digest credentialsttl 2 hours auth_param digest casesensitive on auth_param digest realm Squid proxy for HackWare.ru acl auth_users proxy_auth REQUIRED http_access allow auth_users http_access deny all
Обратите внимание на строку «auth_param digest realm Squid proxy for HackWare.ru», в ней вместо «Squid proxy for HackWare.ru» впишите ту же строку, которую вы указали при использовании команды htdigest.
Пояснение по директивам смотрите выше в разделе «Настройка HTTP Basic аутентификации в Squid».
Обратите внимание, что не только изменена вспомогательная программа (digest_file_auth), но и после неё используется опция -c, за которой следует путь до файла с хешем пароля пользователя. Все остальные директивы схожи с HTTP Basic аутентификацией, за тем исключением, что слово «basic» в них заменено на слово «digest».
Как отключить кэширование в Squid
Кэширование полезная технология, плюсы которой описаны выше. Но если вы используете прокси-сервер для смены своего IP адреса, то в большинстве случаев кэширование не требуется. Но при этом кэш потребляет ресурсы сервера — оперативную память и место на диске.
Если вы хотите отключить кэширование в Squid, то добавьте следующую директиву:
cache deny all
Как блокировать сайты на прокси-сервере Squid
Чтобы заблокировать доступ к нежелательным веб-сайтам, сначала создайте файл с именем «blacklisted_sites.acl», в котором будут храниться сайты из черного списка.
sudo vim /etc/squid/blacklisted_sites.acl
Теперь добавьте веб-сайты, доступ к которым вы хотите заблокировать, например:
.badsite1.com .badsite2.com
Начальная точка сообщает squid о необходимости заблокировать все адреса этих сайтов, включая субдомены www.badsite1, subsite.badsite1.com и так далее.
Теперь откройте файл конфигурации Squid.
sudo vim /etc/squid/squid.conf
И добавьте в него следующие строки:
acl bad_urls dstdomain "/etc/squid/blacklisted_sites.acl" http_access deny bad_urls
Очень важен порядок http_access — если в вашем конфигурационном файле есть описанная выше директива для включения аутентификации на прокси-сервере по паролю («http_access allow auth_users»), то блокировка доменов должна идти перед ней, иначе не будет работать:
Теперь сохраните файл и перезапустите squid:
sudo systemctl restart squid
Эта блокировка работает для сайтов использующих протокол HTTP, а также для сайтов использующих протокол HTTPS. Но в зависимости от используемого протокола сообщение ошибки будет разным. Для сайтов на HTTP будет чёткое сообщение:
ОШИБКА Запрошенный URL не может быть получен
Также для сайтов на HTTP можно настроить свои собственные сообщения об ошибках, в том числе для каждого сайта в отдельности.
Для сайтов на HTTPS будет ошибка «Прокси-сервер отказывается принимать соединения». Различие из-за того, что протокол HTTP позволяет вмешиваться в передаваемый трафик и полностью менять страницу сайта, в данном случае показывая ошибку. Что касается HTTPS, то прокси-сервер не может как-либо модифицировать передаваемые данные, но всё ещё может заблокировать запрос от пользователя на этапе разрешения имён (DNS запрос) или на этапе SSL/TLS-рукопожатия, когда запрашиваемый домен передаётся в открытом виде. Поэтому других мер, кроме как прервать подключение, у прокси нет.
Кроме dstdomain, также имеются такие типы ACL как dstdom_regex (домены по регулярным выражениям), url_regex (поиск совпадение по регулярном выражениям в полном URL), urlpath_regex (поиск совпадение по регулярном выражениям в пути URL) и некоторые другие. Подробнее они рассмотрены в карточке программы:
ССЫЛКА — ещё не готово
Как работает ACL в Squid
Основы ACL в Squid
Остановимся теперь на том, как именно работают ACL.
Схема управления доступом веб-прокси-сервера Squid состоит из двух разных компонентов:
- Элементы ACL — это строки директив, которые начинаются со слова «acl» и представляют типы тестов, которые выполняются для любой транзакции запроса.
- Правила списка доступа состоят из действия allow (разрешения) или deny (запрета), за которым следует ряд элементов ACL, они используются для указания того, какое действие или ограничение необходимо применить для данного запроса. Они проверяются по порядку, и поиск по списку прекращается, как только одно из правил совпадает. Если правило имеет несколько элементов ACL, оно реализуется как логическая операция И (все элементы ACL правила должны выполняться, чтобы правило считалось совпавшим).
Синтаксис acl:
acl ИМЯ ТИП ОПРЕДЕЛЕНИЕ1 ОПРЕДЕЛЕНИЕ2 ОПРЕДЕЛЕНИЕ3 ...
Примеры:
acl localnet src 192.168.0.102 acl Safe_ports port 80 acl accesses_to_google dstdomain .google.com acl accesses_to_search_engines dstdomain .yahoo.com .google.com .vivisimo.com acl accesses_from_marketing_department src 10.52.0.0/16 acl need_to_authenticate proxy_auth
Вы также можете использовать списки определений, которые хранятся в файлах на вашем жёстком диске. Предположим, у вас есть список URL-адресов поисковых систем, которые вы хотите разрешить:
cat /etc/squid/search-engines-urls.txt: .google.com .bing.com .yandex.ru .duckduckgo.com .yahoo.com
Тогда ACL для этого файла будет выглядеть так:
acl accessess_to_search_engines dstdomain "/etc/squid/search-engines-urls.txt"
Кавычки здесь необходимы чтобы сообщить Squid, что ему нужно искать определения в этом файле.
Кроме уже упомянутых типов src, port, dstdomain, proxy_auth имеется десятки других типов, например:
- localip
- localport
- proto
- method
- url_regex
- arp
- browser
- http_status
- req_header
- rep_mime_type
- time
- referer_regex
Полный список вы найдёте в документации squid: http://www.squid-cache.org/Doc/config/acl/. Перевод здесь:
ССЫЛКА — ещё не готово
Сами по себе Элементы acl ничего не меняют в поведение прокси-сервера, это только списки для дальнейшего использования с Правилами списка доступа. Как витиевато сказано в документации, сами по себе эти тесты ничего не делают, например, слово «воскресенье» соответствует дню недели, но не указывает, в какой день недели вы это читаете.
Использование ACL: http_access
Если вы записали только списки управления доступом, то фактически ничего не блокируется — это всего лишь определения. ACL можно использовать в различных местах вашего squid.conf. Самая полезная функция, с которой они могут использоваться в паре, это инструкция http_access. Она работает аналогично тому, как брандмауэр обрабатывает правила. Для каждого запроса, который получает Squid, он будет просматривать все операторы http_access по порядку, пока не найдёт соответствующую строку. Затем он либо принимает, либо отклоняет запрос в зависимости от ваших настроек. Остальные правила, идущие после сработавшего, игнорируются.
Общий синтаксис http_access следующий:
http_access (allow|deny) acl1 acl2 acl3 ...
Примеры:
http_access allow localnet http_access allow localhost http_access deny !Safe_ports http_access deny all http_access allow auth_users http_access allow all
Следующий набор позволит получить доступ администраторам (независимо от того, как выглядит этот ACL; вероятно, ACL src указывает на подсеть, в которой находятся рабочие станции администраторов). Для всех остальных он будет запрещать доступ к URL-адресам porn. Третье правило позволит всем получить доступ к веб-сайтам в обеденное время (кроме сайтов porn). И, наконец, во всех других случаях будет запрет на подключение к Интернету.
http_access allow accesses_from_admins http_access deny accesses_to_porn_urls http_access allow accesses_during_lunchtime http_access deny all
То есть администраторы имеют доступ ко всем сайтам (даже porn) в любое время, а остальные пользователи имеют доступ в сеть только в обеденный перерыв.
Объединение ACL (И/ИЛИ)
Часто вам нужно комбинировать ACL. Допустим, вы хотите разрешить доступ к google.com только для бэк-офиса. Для этого нужно объединить два ACLS с помощью логического И. Это выглядело бы так:
http_access allow accesses_to_google.com accesses_from_back_office
Если вы хотите использовать ИЛИ и сказать, что либо доступ из бэк-офиса, либо доступ к google.com разрешён, правило будет выглядеть так:
http_access allow accesses_to_google.com http_access allow accesses_from_back_office
Подводя итог: для И необходимо размещение условий в одной строке. Для ИЛИ необходимо использование отдельных строк.
Следующий набор правил неправильный, он никогда не сработает:
acl ME src 10.0.0.1 acl YOU src 10.0.0.2 http_access allow ME YOU
Чтобы разрешить доступ через прокси IP адресам 10.0.0.1 и 10.0.0.2 правило нужно записать так:
acl ME src 10.0.0.1 acl YOU src 10.0.0.2 http_access allow ME http_access allow YOU
Другие правила списка доступа
Кроме http_access имеется пара десятков других типов, например:
- http_reply_access
- icp_access
- miss_access
- cache
- url_rewrite_access
Полный список в документации: http://www.squid-cache.org/Doc/config/
Правило http_access по умолчанию
Если во всём конфигурационном файле отсутствуют строки с «http_access», то по умолчанию запрос отклоняется.
Если ни одна из строк «http_access» не приводит к совпадению, значение по умолчанию — противоположно последней строке в списке. Если последняя строка была deny, по умолчанию применяется значение allow. И наоборот, если последняя строка allow, по умолчанию будет применено deny. Мудрёно, да? По этим причинам рекомендуется иметь запись «deny all» в конце ваших списков доступа, чтобы избежать возможной путаницы. То есть после всех правил просто добавляйте строку:
http_access deny all
Итак, вернёмся к нашей комбинации правил «блокировка сайтов + авторизация на прокси-сервере», почему следующий набор неправильный?
http_port 4080 via off auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd auth_param basic children 5 auth_param basic credentialsttl 2 hours auth_param basic casesensitive on auth_param basic realm Squid proxy for HackWare.ru acl auth_users proxy_auth REQUIRED http_access allow auth_users acl bad_urls dstdomain "/etc/squid/blacklisted_sites.acl" http_access deny bad_urls
Дело в том, что вначале срабатывает правило требующее авторизации на сервере, а именно «http_access allow auth_users». Все последующие директивы http_access просто пропускаются, поэтому сайты не блокируются.
Рассмотрим следующий пример:
http_port 4080 via off # Здесь блокировка сайтов acl bad_urls dstdomain "/etc/squid/blacklisted_sites.acl" http_access deny bad_urls auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd auth_param basic children 5 auth_param basic credentialsttl 2 hours auth_param basic casesensitive on auth_param basic realm Squid proxy for HackWare.ru acl auth_users proxy_auth REQUIRED http_access allow auth_users
Поднятая блокировка сайтов срабатывает первой. Причём, ещё даже авторизации на прокси.
Ещё один вариант:
http_port 4080 via off auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd auth_param basic children 5 auth_param basic credentialsttl 2 hours auth_param basic casesensitive on auth_param basic realm Squid proxy for HackWare.ru acl auth_users proxy_auth REQUIRED acl bad_urls dstdomain "/etc/squid/blacklisted_sites.acl" http_access allow auth_users !bad_urls
В этом случае правило срабатывает при соблюдении двух условий: аутентификация и сайт не включён в список заблокированных. Восклицательный знак означает логическое НЕ. Последний вариант является лучшим, логически он более понятный и он выполняет какие-либо действия (блокировку сайта) только после того, как пользователь ввёл логин и пароль прокси-сервера.
Как настроить Squid использовать различные IP адреса
Предположим, у сервера имеется несколько IP адресов — на одном интерфейсе или на разных — не важно.
Задача: использовать разные внешние IP адреса в зависимости от того, к какому порту прокси-сервера происходит обращение.
Итак, как вы можете видеть, на моём тестовом сервере 5 IP адресов, 1 IPv4 адрес и 4 IPv6 адресов:
- 185.117.153.79
- 2a02:f680:1:1100::3d5f
- 2a02:f680:1:1100::3d60
- 2a02:f680:1:1100::3d61
- 2a02:f680:1:1100::3d62
Смотрите также:
- Введение в IPv6 адреса: как пользоваться и как исследовать сеть (часть 1)
- Введение в IPv6 адреса: как пользоваться и как исследовать сеть (часть 2)
Для решения указанной задачи содержимое файла /etc/squid/squid.conf следующее:
# Прокси-сервер будут использовать только локальные утилиты, поэтому разрешён доступ только от localhost. # Если вы хотите подключаться к прокси-серверу из вне, то добавьте к разрешённым соответствующие IP, # либо настройте аутентификацию по паролю. http_access allow localhost http_access deny all # Для подключения к прокси-серверу выбраны порты 24000-24004, следующие строки включают прослушивание этих портов # Обратите внимание, чтобы прокси-сервер не прослушивал внешние IP адреса, кроме порта, указан IP адрес localhost'а http_port 127.0.0.1:24000 http_port 127.0.0.1:24001 http_port 127.0.0.1:24002 http_port 127.0.0.1:24003 http_port 127.0.0.1:24004 # Для каждого порта создаём acl с типом localport acl portA localport 24000 acl portB localport 24001 acl portC localport 24002 acl portD localport 24003 acl portE localport 24004 # Связываем порты и IP адреса tcp_outgoing_address 2a02:f680:1:1100::3d5f portA tcp_outgoing_address 2a02:f680:1:1100::3d60 portB tcp_outgoing_address 2a02:f680:1:1100::3d61 portC tcp_outgoing_address 2a02:f680:1:1100::3d62 portD tcp_outgoing_address 185.117.153.79 portE # Нам не нужен кэш cache deny all
При обращении к странице https://w-e-b.site/ip/ показывается IP адрес клиента, сделавшего запрос. Проверим:
curl https://w-e-b.site/ip/
Выведено:
2a02:f680:1:1100::3d61
Запомним это.
Теперь сделаем обращение к указанной странице через порты прокси-сервера от 24000 до 24003:
curl --proxy localhost:24000 https://w-e-b.site/ip/ curl --proxy localhost:24001 https://w-e-b.site/ip/ curl --proxy localhost:24002 https://w-e-b.site/ip/ curl --proxy localhost:24003 https://w-e-b.site/ip/
Как вы можете видеть, каждый раз выводится разный IPv6 адрес — в соответствии с тем, который из них привязан к определённому порту прокси-сервера.
Как вы думаете, какой IP адрес выведет следующая команда?
curl --proxy localhost:24004 https://w-e-b.site/ip/
Напомню, что к порту 24004 привязан IPv4 185.117.153.79. Если ваш ответ «185.117.153.79», то вы ошибаетесь.
Проверим:
curl --proxy localhost:24004 https://w-e-b.site/ip/
Выведено: 2a02:f680:1:1100::3d61 — это тот же самый IPv6 адрес, который используется по умолчанию.
Причина в том, что на самом деле привязка происходит не к IP адресу как к таковому, а к сетевому интерфейсу, на котором настроен данный IP. Кстати поэтому можно делать привязку и по MAC-адресу. При этом Squid работает следующим образом: если есть техническая возможность (локальный сервер и удалённый хост имеют IPv6 адреса), то по умолчанию используется именно IPv6.
У сайта w-e-b.site есть IPv4 и IPv6 адреса, Squid делает DNS запросы пытаясь получить A и AAAA записи, и если у удалённого хоста есть IPv6 адрес, то используется именно он. Чтобы подключиться к IPv6, сервер также должен использовать IPv6, поэтому выбирается один из доступных IPv6, а не привязанный к порту IPv4.
Смотрите также: Введение в DNS терминологию, компоненты и концепции
Можно ли было бы при привязке порта к IPv4 использовать именно IPv4 соединение даже если доступно IPv6? Технически для этого нет преград, но авторы Squid не сделали такой опции. Но вариант использовать IPv4 также есть, правда, не столь удобный.
Как заставить Squid использовать IPv4, а не IPv6
Поскольку для большинства сетей Интернет IPv6 является таким же быстрым или быстрее, чем Интернет IPv4, Squid предпочитает связываться с веб-сайтами через IPv6.
Опция «dns_v4_first on» меняет порядок предпочтений, чтобы Squid сначала связывался с веб-сайтами с двойным стеком через IPv4. Squid по-прежнему перед подключением будет выполнять запросы к DNS как IPv6, так и IPv4.
ПРЕДУПРЕЖДЕНИЕ. Этот параметр ограничивает ситуации, в которых используется (и проверяется) подключение IPv6. Это приводит к скрытию сетевых проблем, которые в противном случае были бы обнаружены и о которых было бы выведено предупреждение.
Итак, для переключения на IPv4 добавьте в конфигурационный файл следующую опцию:
dns_v4_first on
Теперь запрос через порт 24004 выведет IPv4 адрес:
curl --proxy localhost:24004 https://w-e-b.site/ip/
Но дело в том, что запросы к портам 24000-24003 также будут выводить IPv4 адреса, поскольку удалённый хост использует и те и другие, а по умолчанию теперь выбираются IPv4.
То есть по сути эта опция представляет собой переключение между IPv4 и IPv6. Это не совсем удобно и немного алогично. Нужно помнить об этом, поскольку используя различные IP адреса на одном прокси-сервере, вы можете заблуждаться о том, какой именно из них используется на самом деле.
Начиная с пятой версии Squid опция dns_v4_first будет удалена. Вместо того, чтобы подчиняться настройкам dns_v4_first, порядок использования семейства IP теперь в основном контролируется временем ответа DNS: если ответ DNS AAAA приходит первым, пока Squid ожидает IP-адреса, то Squid будет использовать сначала полученные IPv6-адреса. Для ранее кэшированных IP-адресов Squid сначала пробует адреса IPv6. Для управления семейством IP-адресов, используемых Squid, администраторы должны использовать межсетевые экраны, конфигурацию рекурсивного преобразователя DNS и/или —disable-ipv6. При планировании изменений конфигурации имейте в виду, что предстоящие улучшения Happy Eyeballs будут способствовать более быстрому установлению TCP-соединения, уменьшая влияние времени разрешения DNS.
В пятой версии реализован алгоритм «Happy Eyeballs», который использует полученный IP сразу же, как он понадобиться. Правила файерволов, запрещающие IPv6 TCP подключения, остаются предпочитаемым методом конфигурации для «отключения» подключений по IPv6, с конфигурацией рекурсивного преобразователя DNS.
Как добавлять, изменять и удалять HTTP заголовки в Squid
Прокси-сервер Squid позволяет произвольно менять, удалять и добавлять HTTP заголовки к ответам и запросам.
Важно: обратите внимание, что манипуляции с заголовками возможны ТОЛЬКО для HTTP подключений, в HTTPS трафике всё передаётся в зашифрованном виде и прокси-сервер не имеет доступ к заголовкам.
Директивы для обработки заголовков запросов:
- request_header_access — позволяет удалять заголовки, если этой директивой удалён заголовок, то также проверяются записи request_header_replace, и если найдено подходящее правило для заголовка, то он меняется, если нет, то остаётся как есть (удалённым)
Следующий пример удалит из всех запросов HTTP заголовки From, Referer и User-Agent.
request_header_access From deny all request_header_access Referer deny all request_header_access User-Agent deny all
В следующих правилах перечислены HTTP заголовки, которые должны быть сохранены, остальные будут удалены:
request_header_access Authorization allow all request_header_access Proxy-Authorization allow all request_header_access Cache-Control allow all request_header_access Content-Length allow all request_header_access Content-Type allow all request_header_access Date allow all request_header_access Host allow all request_header_access If-Modified-Since allow all request_header_access Pragma allow all request_header_access Accept allow all request_header_access Accept-Charset allow all request_header_access Accept-Encoding allow all request_header_access Accept-Language allow all request_header_access Connection allow all request_header_access All deny all
- request_header_replace — меняет заголовки, которые были отклонены request_header_access.
Пример подмены User-Agent:
request_header_access User-Agent deny all request_header_replace User-Agent Nutscrape/1.0 (CP/M; 8-bit)
- request_header_add — добавляет HTTP заголовки к запросам.
Пример:
request_header_add X-Client-CA "CA=%ssl::>cert_issuer" all
Аналогичные директивы для манипуляции заголовков в ответах:
- reply_header_access
- reply_header_replace
- reply_header_add
Вопросы и ответы по настройки и использованию Squid. Примеры конфигураций Squid
Как настроить веб-браузер (или Windows) для работы через прокси
Настройку Windows и Linux, а также веб-браузеров в этих операционных системах смотрите в статье «Настройка клиентов и операционных систем для работы через прокси».
Разрешение доступа на определённые сайты по паролю
Рассмотрим, как настроить разрешение доступа на определённые сайты только аутентифицированным пользователям. Допустим, мы хотим использовать прокси-сервер для ограничения доступа на некоторые сайты — но не просто для блокировки, а с возможностью ввести пароль и получить доступ к сайту.
В качестве пароля будем использовать аутентификацию на прокси сервере.
Список сайтов, доступ к которым доступен только по паролю, расположен в файле /etc/squid/restricted_sites.acl, тогда конфигурация следующая:
# Прокси сервер работает на 4080-м порту, без отправки HTTP заголовка Via и без кэширования http_port 4080 via off cache deny all # Настройка аутентификации auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd auth_param basic children 5 auth_param basic credentialsttl 2 hours auth_param basic casesensitive on auth_param basic realm Squid proxy for HackWare.ru acl auth_users proxy_auth REQUIRED # Добавляем правило со списком ограниченных к доступу сайтов: acl restricted_urls dstdomain "/etc/squid/restricted_sites.acl" # Если пользователь пытается открыть сайты из правила restricted_urls, то появляется окно аутентификации на сервере # Пока не будет введён пароль от прокси, невозможно открыть ограниченные сайты http_access allow restricted_urls auth_users # Все остальные сайты свободно доступны без пароля http_access allow all
Как в URL блокировать определённые ключевые слова с помощью Squid
Чтобы заблокировать список ключевых слов, которые могут встречаться в URL, сначала создайте файл с именем «blockkeywords.lst», в котором будут храниться ключевые слова из чёрного списка.
sudo vim /etc/squid/blockkeywords.lst
Теперь добавьте ключевые слова, к которым вы хотите заблокировать доступ, например:
facebook instagram Gmail new-life-2021 bablo vk
Теперь откройте файл конфигурации Squid и добавьте следующее правило — размещайте строки «http_access deny» (с блокировкой) выше строк с разрешением:
acl blockkeywordlist url_regex "/etc/squid/blockkeywords.lst" http_access deny blockkeywordlist
Теперь сохраните файл и перезапустите squid:
sudo systemctl restart squid
Обратите внимание, опять имеется разница в обработке сайтов на HTTPS и HTTP. Если поиск выполняется по части доменного имени, то данные правила будут работать в любом случае, но ошибки вновь будут отображаться по-разному. Поиск по пути URL за пределами доменного имени работает только для сайтов на HTTP. При использовании HTTPS весь трафик, в том числе адреса запрашиваемых страниц, передаётся в зашифрованном виде, поэтому возможность фильтровать отсутствует в принципе.
Конфигурация Squid для различных пользователей
Если вы предпочитаете делать настройки в отдельных файлах, то вы можете в основной конфигурационный файл (/etc/squid/squid.conf) добавить директиву include, например:
include /path/to/included/file/squid.acl.config
В результате будут импортированы настройки из указанного файла.
Поддерживаются кавычки и подстановочные символы, то есть если добавить следующую директиву:
include /etc/squid/conf.d/*
То в результате будут включены настройки из всех файлов, находящихся в директории /etc/squid/conf.d/.
Включаемые элементы могут быть вложены до 16 уровней глубины (ограничение установлено в исходном коде программы). Это произвольное ограничение не позволяет рекурсивным ссылкам include заставлять Squid входить в бесконечный цикл при попытке загрузить файлы конфигурации.
Запуск Squid без перевода в фон
Выше показано, как запустить Squid как службу. Но вы можете запустить прокси-сервер как обычную программу, без перевода в фон. Чтобы процесс не уходил в фон, используйте опцию -N:
squid -N
Другие опции, которые вам могут пригодиться в командной строке:
-a ПОРТ Указать номер порта HTTP (по умолчанию: 3128). -d УРОВЕНЬ Записывать сообщения отладки также и в stderr. -f ФАЙЛ Использовать этот конфигурационный файл вместо /etc/squid/squid.conf
Как заблокировать все адреса назначения кроме одного
Эта настройка разрешит доступ только к IP адресу 10.0.0.1:
acl GOOD dst 10.0.0.1 http_access allow GOOD http_access deny all
Аналогичное правило вы можете настроить для доменов, используя такие типы acl как dstdomain и url_regex.
Как только одному адресу разрешить доступ к определённому URL
В этом примере только special_client разрешается доступ к special_url. Любой другой клиент, который пытается получить доступ к special_url, отклоняется.
acl special_client src 10.1.2.3 acl special_url url_regex ^http://www.squid-cache.org/Doc/FAQ/$ http_access allow special_client special_url http_access deny special_url
Почему в Squid рекомендуется блокировать некоторые порты
Имеются номера портов, к которым опасно разрешать Squid подключаться. Например, было продемонстрировано, что кто-то может использовать Squid в качестве ретранслятора SMTP (электронной почты). Как я уверен, вы знаете, ретрансляторы SMTP — это один из способов, с помощью которых спамеры отсылают свои письма. Чтобы предотвратить ретрансляцию почты, Squid отклоняет запросы, когда номер порта URL равен 25. Другие порты также должны быть заблокированы в качестве меры предосторожности против других менее распространённых атак.
Есть два способа фильтрации по номеру порта: разрешить определённые порты или запретить определённые порты. По умолчанию Squid использует первый вариант. Это запись ACL в файле squid.conf по умолчанию:
acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https 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 http_access deny !Safe_ports
Для краткости её можно было бы записать так:
acl Safe_ports port 80 21 443 70 210 1025-65535 280 488 591 777 http_access deny !Safe_ports
Приведённая выше конфигурация отклоняет запросы, когда номер порта URL отсутствует в списке. Список позволяет подключаться к стандартным портам для HTTP, FTP, Gopher, SSL, WAIS и всем непривилегированным портам.
Другой подход — запретить опасные порты. Список опасных портов должен выглядеть примерно так:
acl Dangerous_ports port 7 9 19 22 23 25 53 109 110 119 http_access deny Dangerous_ports
…и, вероятно, многие другие.
Пожалуйста, обратитесь к файлу /etc/services в вашей системе для получения списка известных портов и протоколов.
Поскольку по умолчанию в конфигурации squid разрешены только определённые порты, если вы хотите добавить больше, просто укажите их в файле конфигурации, как показано:
acl Safe_ports port XXX
Где XXX — номер порта, который вы хотите разрешить. Опять же, рекомендуется оставлять комментарий рядом с acl, который будет описывать, для чего будет использоваться порт.
Чтобы изменения вступили в силу, вам нужно будет перезапустить squid ещё раз.
sudo systemctl restart squid
Как посмотреть, какие IP адреса прослушивает прокси-сервер Squid
Следующая команда выведет список портов и интерфейсов, которые прослушивают процессы Squid:
ss -tulpn | grep squid
Смотрите также: Как проверить открытые порты на своём компьютере. Что означают 0.0.0.0, :*, [::], 127.0.0.1. Как понять вывод NETSTAT
Как сделать так, чтобы прокси-сервер Squid прослушивал только локальный порт
По умолчанию, если с директивой http_port указать только порт, то он будет прослушиваться на всех интерфейсах, в том числе и на внешних:
http_port 24000 http_port 24001 http_port 24002
Вы можете явно указать IP адрес интерфейса, который на котором прокси-сервер должен открыть порт:
http_port IP:ПОРТ
Пример, когда с прокси-сервером должны работать только локальные приложения-пользователи:
http_port 127.0.0.1:24000 http_port 127.0.0.1:24001 http_port 127.0.0.1:24002
Почему Squid открывает UDP порты
Если посмотреть, какие-порты открывает прокси сервер Squid
ss -tulpn | grep squid
то можно увидеть, что кроме TCP порта, который указан в конфигурации Squid, также присутствуют 2 UDP порта.
Прокси-сервер Squid открывает 2 произвольных UDP порта во время своей работы. Причём открывает их на всех интерфейсах, в том числе на доступных для внешнего подключения. Зачем это делается? Официальное объяснение можно прочитать здесь: http://www.squid-cache.org/mail-archive/squid-users/200009/0750.html. Суть в том, что для своей работы Squid делает DNS запросы и открытые UDP порты ему нужны чтобы принимать DNS ответы.
Как настроить кэширование в прокси-сервере Squid
[ДОПИСЫВАЕТСЯ]
Поддерживает ли Squid SOCKS4 или SOCKS5
Нет, протокол SOCKS не поддерживается. Разработчики пишут, что для этого нет технических преград и, в принципе, реализация поддержки SOCKS должна быть не сложной, но не делают этого. Видимо, им это неинтересно.
Директивы из минимальной рекомендуемой конфигурации
В этой статье показаны примеры настройки прокси-сервера с нуля, чтобы уже имеющиеся директивы не приводили к непредвиденным результатам.
Тем не менее, некоторые настройки, такие как рассмотренные выше блокировки портов, важны. В рекомендуемой минимальной конфигурации имеются директивы, которые не стоит терять:
# Разрешаем доступ к cachemgr только от localhost http_access allow localhost manager http_access deny manager # Мы настоятельно рекомендуем раскомментировать следующее, чтобы защитить невинные веб-приложения, # работающие на прокси-сервере, которые думают, что единственный, кто может получить доступ # к службам на "localhost", - это локальный пользователь. #http_access deny to_localhost
На самом деле, защита от пользователей нужна только в том случае, если вы создаёте публичный прокси-сервер, а не только для личного использования.
Как настроить работы прокси Squid с множеством пользователей
К примеру, задача организовать работу Squid с несколькими пользователями, каждый из которых в качестве настроек прокси получил IP адрес (одинаковый у всех) и номер порта (индивидуален у каждого пользователя). Также у пользователей индивидуальны логин и пароль. Сервер имеет несколько внешних IP (в данном случае IPv6) адресов, необходимо сделать так, чтобы каждый из пользователей выходил по индивидуальному IP адресу.
Допустим на входе имеем 127.0.0.1:1000:test1:pass1, а на выходе 2a02:f680:1:1100::3d60.
И на входе 127.0.0.1:1001:test2:pass2 и на выходе 2a02:f680:1:1100::3d61.
Решение:
Начинаем с заполнения учётных данных пользователей (раздел «Настройка подключения к прокси-серверу Squid по логину и паролю»):
sudo htpasswd -c /etc/squid/passwd test1 sudo htpasswd /etc/squid/passwd test2
В последующем конфигурационном файле вам нужно заменить:
- имена пользователей на выбранные вами имена
- прописать желаемые порты
- прописать желаемые IPv6 или IPv4 адреса как для прослушивания, так и в качестве исходящих адресов
- продублировать аналогичные записи для каждого пользователя (порта, IP адреса)
Содержимое моего файла /etc/squid/squid.conf:
# Настройки аутентификации auth_param basic program /usr/lib64/squid/basic_ncsa_auth /etc/squid/passwd auth_param basic children 5 auth_param basic credentialsttl 2 hours auth_param basic casesensitive on auth_param basic realm Squid proxy for HackWare.ru # Порты для прослушивания http_port 185.117.153.79:1000 http_port 185.117.153.79:1001 # Для каждого порта создаём acl с типом localport acl portA localport 1000 acl portB localport 1001 # Связываем порты и IP адреса tcp_outgoing_address 2a02:f680:1:1100::3d60 portA tcp_outgoing_address 2a02:f680:1:1100::3d61 portB # Для каждого пользователя создаём acl с типом proxy_auth acl test1_user proxy_auth test1 acl test2_user proxy_auth test2 # Разрешаем доступ двух связок acl: # пользователь test1 и порт 1000 # пользователь test2 и порт 1001 http_access allow test1_user portA http_access allow test2_user portB
Настройка Squid для работы с OpenVPN
Вы можете использовать прокси Squid для подключение через него к OpenVPN.
Настройка прокси-сервера Squid для работы с OpenVPN не требует каких-то специальных опций. Например, для использования Squid в качестве прокси-сервера для подключения к OpenVPN без аутентификации достаточно указать следующие строки в конфигурационном файле (замените порт 45600 любой другой):
http_port 45600 acl portA localport 45600 http_access allow portA
Дополнительно вы можете настроить Basic или Digest аутентификацию — OpenVPN поддерживает их обе.
Помните, что того, чтобы работало подключение к OpenVPN через HTTP прокси необходимо, чтобы OpenVPN сервер использовал протокол TCP.
Смотрите также: Как использовать OpenVPN с протоколом TCP
Как отредактировать страничку блокировки в Squid? Вставить свои картинки и почту?
Настраиваемая страничка блокировки может быть показана только если пользователь подключается по HTTP протоколу. Для HTTPS соединений (которых в настоящее время подавляющее большинство) подменить показываемую страницу (то есть вывести настроенную страничку блокировки) невозможно из-за самой природы HTTPS, который как раз и предназначен для обеспечения невозможности модификации передаваемых данных.
То есть можно отредактировать страничку блокировки в Squid, но она будет показываться в тех немногих случаях, когда выполняется соединение по HTTP.
Для HTTPS соединений будет показываться стандартная страница веб-браузера с сообщение вроде «Прокси-сервер отказывается принимать соединения» (“The proxy server is refusing connections”).
То есть можно констатировать, что пользовательская страница блокировки в Squid будет применяться довольно редка и её настройку можно отнести скорее к устаревшему функционалу.
Squid имеет шаблоны страниц с различными сообщениями, в том числе о запрете доступа, на разных языках. К примеру: /usr/share/squid/errors/ru/ERR_ACCESS_DENIED — это страница с сообщением «Запрошенный URL не может быть получен». Аналогичная страница на английском – /usr/share/squid/errors/en/ERR_ACCESS_DENIED («ERROR: The requested URL could not be retrieved»).
Можно отредактировать эту страницу как обычный HTML файл.
На этой страницы используются коды для вставки в шаблон, например:
- %U
- %c
- %w
- %W
Значение этих кодов, а также многие другие коды вы найдёте на следующей странице: https://wiki.squid-cache.org/Features/CustomErrors
Как установить e-mail менеджера кэша Squid?
Если вы хотите только указать e-mail адрес менеджера кэша Squid, то вам необязательно редактировать файлы шаблонов. Вы можете использовать следующие директивы:
- cache_mgr — это адрес электронной почты менеджера локального кеша, который будет получать почту, если кеш умрет. По умолчанию «webmaster».
- email_err_data — если этот параметр включён, информация о возникшей ошибке будет включена в почтовые ссылки страниц ERR (если установлено значение %W), чтобы данные содержались в теле письма. Синтаксис: <A HREF="mailto:%w%W">%w</A>. По умолчанию уже включено, поэтому дополнительно настраивать не нужно.
Возможные ошибки и проблемы при использовании прокси-сервера
Ошибка «Прокси-сервер отказывается принимать соединения»
Данная ошибка возникает если:
- прокси-сервер выключен
- вы пытаетесь подключиться к неверному порту
- вы пытаетесь подключиться к неверному IP
- прокси-сервер настроен отклонять запросы от вашего IP адреса
Squid может открыть сайты по HTTP протоколу, но не может открыть HTTPS
Если вы столкнулись с ситуацией, когда HTTP сайты открываются нормально, а для HTTPS сайтов показывается сообщение:
Прокси-сервер отказывается принимать соединения
то возможной причиной может быть то, что вы настроили свой браузер или систему работать с HTTP прокси, но не настроили их работать с HTTPS прокси — это разные типы прокси и они оба нуждаются в настройках.
По умолчанию Squid выступает и в роли HTTP прокси, и в роли HTTPS прокси, а клиенты должны настраивать оба этих типа.
Ошибка «Authentication helper program /usr/lib64/squid/basic_ncsa_auth: (2) No such file or directory»
Если при настройки входа по паролю ваш прокси-сервер не запускается и при проверки статуса службы выдаёт ошибку:
Authentication helper program /usr/lib64/squid/basic_ncsa_auth: (2) No such file or directory
то вам нужно проверить путь до файла basic_ncsa_auth.
Возможно вместо пути /usr/lib64/squid/basic_ncsa_auth вам следует использовать /usr/lib/squid/basic_ncsa_auth.
Ошибка «Authentication helper program /usr/lib/squid/basic_ncsa_auth: (2) No such file or directory»
Ошибка аналогичная предыдущей, но вместо пути /usr/lib/squid/basic_ncsa_auth попробуйте использовать /usr/lib64/squid/basic_ncsa_auth.
VPS для прокси-сервера
Если вы хотите настроить прокси-сервер на VPS сервере, то я могу порекомендовать парочку хостингов:
- отечественный, очень недорогой (работаю с ним с 2016 года, всё очень нравится, именно там хостится SuIP.biz)
- иностранный с возможностью выбора дата-центра из разных стран (работаю с ним с 2019, тоже всё очень нравится)
Связанные статьи:
- Как подключаться к OpenVPN через прокси или Tor (66.6%)
- Инструкция по настройке сервера и клиента OpenVPN (54%)
- Типичные ошибки, приводящие к деанонимизации (54%)
- Решение проблемы «W: не удалось получить http://http.kali.org/kali/dists/kali-rolling/InRelease» из-за блокировок провайдера (53.6%)
- Продвинутое использование OpenVPN (53.6%)
- Как защитить веб сервер на Kali Linux от доступа посторонних (RANDOM - 0.5%)
Статья будет дополняться — ещё много интересных моментов не раскрыто.
Если у вас вопросы или просто есть что сказать по теме прокси-серверов (интересные примеры использования или настройки), то пишите в комментариях!
Интересно, а можно сделать авторизацию к каждой проксе с разным логином и паролем ? Если да, то как это реализовать ?
Можно запустить несколько экземпляров Squid в которых будут индивидуальные настройки, в том числе учётные записи пользователей. ИМХО, это имеет смысл только если у сервера несколько сетевых интерфейсов.
Если сетевой интерфейс один, то можно запустить несколько экземпляров Squid (или в одном экземпляре Squid прослушивать несколько портов), но запросы к конечным серверам всё равно будут отправляться с одного IP. То есть даже если настроить подключение к разным портам с разными учётными данными, то уходить они будут с одного сетевого интерфейса — сделать можно, но смысла нет.
Систему так грузить будет я думаю достаточно. У меня сейчас на 3proxy 100 пользователей. Каждый со своим логином и паролем, удобно и никаких лишних телодвижений не приходится делать. В сквид я думаю можно так же сделать, пока думаю как )
И все выходят через один IP?
И в Squid можно сделать сколько угодно учётных записей пользователя. Если суть в том, чтобы все подключались к одному и тому же IP и порту и выходили с одного IP, то всё элементарно — просто делается нужное количество аккаунтов и всё. Но смысла в этом ровно ноль.
Как я догадываюсь, цель комментария «рассказать какой я молодец», но вопрос, на самом деле, интересный.
Можно создавать правила вида
И с помощью них делать разнообразную тонкую настройку:
«рассказать какой я молодец» — совсем нет.
Хотел придти к вопросу , не смог найти ответа к нему. Как на сквиде сделать аутентификацию по порту к примеру, вот допустим я подниму ipv6.
На входе 127.0.0.1:1000:test1:pass1 на выходе 27a03:473f:2194c::23ccf
и.127.0.0.1:1001:test2:pass2 на выходе
27a03:473f:2194c::23cff
Вот нигде не могу найти инструкции по такой конфигурации. И да, статья ваша прекрасная.
Конфигурационный файл ниже под указанные условия, кроме того, что IPv6 я поменял на свои, прослушивание тоже настроил на внешний интерфейс — всё это в целях тестирования, то есть это 100% работающая конфигурация, проверенная. Замените 185.117.153.79:1000 на 127.0.0.1:1000 или на что вам надо.
Начинаем с заполнения учётных данных пользователей (раздел «Настройка подключения к прокси-серверу Squid по логину и паролю»):
Содержимое файла /etc/squid/squid.conf:
Огромное спасибо за ваш труд, очень информативная статья для новичка.
Привет. По теме 3proxy. Попробуй в первой строке конфига(/etc/3proxy.cfg) указать "daemon". Мне помогло.
Пример:
daemon
nserver 8.8.4.4
nserver 8.8.8.8
… дальше остальное
Спасибо! Когда-нибудь попробую.
Как отредактировать станичку блокировки ? Вставить свои картинки и почту?
Приветствую! Я добавил раздел «15.17 Как отредактировать страничку блокировки в Squid? Вставить свои картинки и почту».