SCROLL

Посты с тэгом: Squid

Разберем как установить из исходников актуальную (на момент написания статьи) версию кеширующего прокси-сервера Squid 5.5 на Debian 10 Buster.

[stextbox id=’info’]ИНФОРМАЦИЯ. Хочу сообщить что ниже описанное руководство, так же применимо к установке младших версии Squid 4, 5.x[/stextbox]

 

Установка прокси-сервера Squid

Устанавливаем необходимые зависимости для сборки и работы Squid:

apt-get update
apt-get install build-essential make libssl-dev libkrb5-dev libldap2-dev libk5crypto3 libsasl2-dev libpam0g libcap2-dev

Скачиваем и распаковываем исходники Squid:

cd /opt/
wget http://www.squid-cache.org/Versions/v5/squid-5.5.tar.gz
tar -zxvf squid-5.5.tar.gz
cd squid-5.5

Выполняем конфигурирование с поддержкой HTTPS:

./configure --prefix=/usr --localstatedir=/var --libexecdir=/usr/lib/squid --datadir=/usr/share/squid --sysconfdir=/etc/squid --enable-ssl-crtd --with-openssl --enable-translation --enable-cpu-profiling --disable-dependency-tracking --disable-ipv6 --enable-removal-policies="lru,heap" -enable-delay-pools --enable-icmp --enable-linux-netfilter --enable-external-acl-helpers --with-large-files --with-default-user=proxy --with-logdir=/var/log/squid --with-pidfile=/var/run/squid.pid

Собираем и устанавливаем пакет Squid:

make
make install

Создаем необходимые каталоги, для работы Squid и назначаем для них права доступа:

mkdir -p /var/log/squid
mkdir -p /etc/squid/ssl

chown proxy:proxy /var/log/squid
chown proxy:proxy /etc/squid/ssl
chmod 700 /var/log/squid
chmod 700 /etc/squid/ssl

Создаем стартовый скрипт Squid — /etc/init.d/squid:

У одного из читателей блога наблюдалась проблема в произвольной перезагрузке Squid при работе в режиме перехвата HTTPS трафика с использованием «bump all». В логах (/var/log/squid/cache) в момент перезагрузки Squid появляется запись assertion failed: http.cc:1533: «!Comm::MonitorsRead(serverConnection->fd)».

 

Решается данная проблема путем применения не-официального патча (long-term fix for v4, take2 (unofficial)). В ниже описанном порядке действий, можно использовать материалы по сборке Squid c поддержкой HTTPS:

В работе имеется прокси-сервер Squid 4.9, работающий с HTTPS поддержкой. Столкнулся с проблемой в работе мессанджера Whatsapp (Web, Desktop версии) на конечных системах.

 

Проблема заключается в том что web, desktop версии Whatsapp не соединяются со своими серверами и выдают сообщение что отсутствует подключение к сети интернет. В логах Squid (access.log) видны следующие события при попытке Whatsapp установить соединение:

1582785108.113    154 10.10.15.9 TCP_MISS/400 231 GET https://web.whatsapp.com/ws - ORIGINAL_DST/31.13.72.52 -
1582785108.278    161 10.10.15.9 TCP_REFRESH_MODIFIED/200 390 GET https://web.whatsapp.com/status.json - ORIGINAL_DST/31.13.72.52 text/json

 

Видно что приложение пытается открыть WebSocket соединение, о чем свидетельствует /ws в строке запроса. Так же в браузере при просмотре кода можно увидеть что не удается выполнить WebSocket соединение (WebSocket connection to ‘wss://web.whatsapp.com/ws’ failed: Error during WebSocket handshake: Unexpected response code: 400)

Рассмотрим как реализовать перехват пользовательских HTTPS-запросов в сеть интернет для дальнейшего анализа и учета их. Все ниже описанные действия производятся на Debian 9 Stretch с установленным прокси-сервером Squid 4.9.

 

Для работы с HTTPS трафиком необходимо, чтобы Squid был собран с следующими параметрами:

--enable-ssl-crtd --with-openssl

[stextbox id=’warning’]ПОДСКАЗКА. Как собрать из исходников Squid 4.9 с необходимыми параметрами, можно посмотреть из этой статьи.[/stextbox]

 

Для просмотра HTTPS трафика, прокси-сервер Squid должен иметь свой собственный СА сертификат, который используется для подписывания динамически генерируемых сертификатов для серверов, к которым пользователи посылают запросы.

 

Выполним генерацию CA сертификата и назначим права доступа для него, выполним команды:

cd /usr/local/etc/squid/ssl
openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -keyout squidca.pem -out squidca.pem

chown proxy:proxy squidca.pem 
chmod 640 squidca.pem

 

Конвертируем сертификат в формат для импорта на пользовательские системы:

openssl x509 -outform der -in squidca.pem -out squidca.crt

[stextbox id=’warning’]ПОДСКАЗКА. Как скачать сертификат из Linux системы в Windows, можно посмотреть из этой статье.[/stextbox]

[stextbox id=’info’]Полученный сертификат необходимо установить в «Доверенные корневые сертификаты» на все пользовательские компьютеры, которые будут работать через прокси-сервер Squid. В доменной среде это проще всего сделать при помощи GPO (Group Policy objects).[/stextbox]

Разберем как настроить связь Squid 4.9 c Active Directory через Kerberos аутентификацию и Basic LDAP авторизацию, для предоставления доступа в интернет по доменным учетным записям и разграничение прав согласно заданным группам безопасности Active Directory.

 

Исходные данные:

  • Контроллер домена (DC1) на Windows Server 2012 R2, домен JAKONDA.LOCAL
  • Прокси-сервер Squid 4.9 (squid) на Debian 9 Stretch

 

Подготовка системы (Debian 9 Stretch)

Перед началом выполнения ниже описанных действий обновляем систему до актуального состояния:

apt-get update && apt-get upgrade -y

 

Указываем FQDN (Fully Qualified Domain Name) имя системы, в файле (/etc/hostname):

squid.jakonda.local

 

Так же файл (/etc/hosts) приводим к виду таким образом, чтобы в нём была запись с полным доменным именем компьютера и с коротким именем, ссылающаяся на один из внутренних IP:

127.0.0.1	localhost
127.0.1.1	squid.jakonda.local squid

 

Настраиваем синхронизацию времени с контроллером домена, выполняем установку NTP, выполняем синхронизацию времени с контроллером домена:

apt-get install ntp ntpdate

ntpdate dc1.jakonda.local

[stextbox id=’info’]Более подробно о синхронизации времени на Debian 8 Jessie/Ubuntu Server 14.04 можно почитать в этой статье[/stextbox]

Рассмотрим как установить из исходников актуальную (на момент написания статьи) версию кеширующего прокси-сервера Squid 4.6 на Debian 9 Stretch.

[stextbox id=’info’]ИНФОРМАЦИЯ. Хочу сообщить что ниже описанное руководство, так же применимо к установке версии Squid 4.9.[/stextbox]

 

Подготовка системы

Обновляем систему до актуального состояния:

apt-get update && apt-get upgrade

Устанавливаем необходимые пакеты для сборки и работы squid:

apt-get install autoconf automake autopoint autotools-dev binutils build-essential cdbs comerr-dev cpp cpp-6 debhelper dh-autoreconf dh-strip-nondeterminism dpkg-dev g++ g++-6 gcc gcc-6 gettext icu-devtools intltool-debian krb5-multidev libarchive-zip-perl libasan3 libatomic1 libc-dev-bin libc6-dev libcap-dev libcc1-0 libcilkrts5 libcppunit-1.13-0v5 libcppunit-dev libcroco3 libdb-dev libdb5.3-dev libdpkg-perl libecap3 libecap3-dev libexpat1-dev libfile-stripnondeterminism-perl libgcc-6-dev libgmp-dev libgmpxx4ldbl libgnutls-dane0 libgnutls-openssl27 libssl-dev libgnutls28-dev libgnutlsxx28 libgomp1 libgssrpc4 libicu-dev libidn11-dev libisl15 libitm1 libkadm5clnt-mit11 libkadm5srv-mit11 libkdb5-8 libkrb5-dev libldap2-dev liblsan0 libltdl-dev libltdl7 libmpc3 libmpfr4 libmpx2 libnetfilter-conntrack-dev libnfnetlink-dev libp11-kit-dev libpam0g-dev libquadmath0 libsasl2-dev libsigsegv2 libstdc++-6-dev libtasn1-6-dev libtimedate-perl libtool libtsan0 libubsan0 libunbound2 libxml2-dev linux-libc-dev m4 make nettle-dev patch pkg-config po-debconf zlib1g-dev

 

Установка прокси-сервера Squid

Скачиваем исходник «squid», распаковываем его:

cd /opt/
wget http://www.squid-cache.org/Versions/v4/squid-4.6.tar.gz
tar -zxvf squid-4.6.tar.gz 
cd squid-4.6

Пользователи всегда норовят что либо скачать из интернета и часто скачивают вредоносное ПО, тем самым подвергая опасности другие ПК в локальной сети и целостность их данных. Поэтому сейчас мы на примере рассмотрим как бороться с этим явлением используя прокси-сервер Squid 3.5.19.

Все операции проделываться будут на Ubuntu server 14.04.5 с развернутым Squid 3.5.19 по этой инструкции и опираясь на представленный в инструкции конфиг Squid.

Создадим текстовый файл, в котором будут хранится список всех нежелательных элементов URL, содержащие имена файлов с расширениями.

sudo nano /etc/squid/blockfiles.txt

Указываем в файле все нежелательные расширения файлов, которые необходимо блокировать:

\.[Aa][Vv][Ii]$ #Блокировка - .avi
\.[Mm][Pp][Gg]$ #Блокировка - .mpg
\.[Mm][Pp][Ee][Gg]$ #Блокировка - .mpeg
\.[Ff][Ll][Vv]$ #Блокировка - .flv
\.[Mm][Pp]3$ #Блокировка - .mp3

[note]Информация: расширение файлов указано в формате прим. [Mm][Pp]3 чтобы исключить варианты расширений вида: mP3, MP3, Mp3.. Указанный нами формат расширения, исключает возможность любого варианта написания данного расширения.[/note]

Контролируем предоставления доступа в интернет по времени и дням недели. Не будем оставлять повода сотрудникам задерживаться на работе, дабы посидеть в интернете.

Все операции проделываться будут на Ubuntu server 14.04.5 с развернутым Squid 3.5.19 по этой инструкции и опираясь на представленный в инструкции конфиг Squid.

Блокировать доступ мы будем с помощью acl — time. Синтаксис acl такой: acl [название правила] time [аббревиатура дней] [h1:m1-h2:m2].

Коды дней недели определяются так: S — Sunday — Воскресенье, M — Monday — Понедельник, T — Tuesday — Вторник, W — Wednesday — Среда, H — Thursday — Четверг, F — Friday — Пятница, A — Saturday — Суббота. А параметры h1:m1 и h2:m2 вставляется время.

[tip]Важно !  h1:m1 всегда должно быть меньше h2:m2[/tip]

Рано или поздно все сталкиваются с задачей ограничения скорости доступа в интернет для пользователей. Рассмотрим решение данной задачи при помощи прокси-сервера Squid (установить его можно по этой статье)

 

За ограничение скорости в Squid отвечает параметр delay_pools. Принцип работы delay_pools каждый запрашиваемый объект сначала попадает в пул, а затем передается клиенту. Каждый пул определяется двумя параметрами: скоростью его заполнения и размером буфера. Прим. размер пула 8000 и размер буфера 8000, означает что скорость заполнения буфера будет 64 кБ/с. Неограниченный размер буфера и скорости задается как -1/-1. Размер буфера и скорость задается в байта.

 

Скорость заполнения пула зависит от класса delay_class. Варианты доступных классов:

  1. Общие ограничения скорости загрузки для всех.
  2. Общие ограничения скорости загрузки и скорость каждого хоста.
  3. Общие ограничения скорости загрузки, скорость сети и скорость каждого хоста.
  4. Все ограничения класса 3 + ограничения на уровне отдельно взятых пользователей (требуется аутентификация пользователей в правилах http_access).
  5. Запросы группируются по тэгам определяемым в external_acl

 

Вид записей delay_parameters, в зависимости от выбранного класса:

  1. delay_parameters <номер пула> <общие ограничения для всех>
  2. delay_parameters <номер пула> <общие ограничения для всех> <ограничения для хоста>
  3. delay_parameters <номер пула> <общие ограничения для всех> <ограничения для подсети> <ограничения для хоста>
  4. delay_parameters <номер пула> <общие ограничения для всех> <ограничения для подсети> <ограничения для хоста> <ограничения для пользователя>
  5. delay_parameters <номер пула> <тегированные ограничения>

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

 

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

 

[stextbox id=’alert’]Сразу хочу предупредить, что выполнить перенаправление на заданную страницу в Squid возможно только при посещении пользователем HTTP сайтов. К сожалению с HTTPS сайтами перенаправление работать не будет. [/stextbox]

 

Проделываться все будет на Squid 3.5.19 (статья по установке) установленным на Ubuntu server 14.04. Но уверен что способы будут работать и на отличных от моих параметров.

Появилась необходимость настроить Squid 3.5.19 с авторизацией по логину и паролю. Т.е. чтобы при попытке посетить какой либо интернет ресурс пользователю выдавался запрос авторизации, в случае успешной авторизации доступ в интернет предоставлялся, в ином случае, пользователь получал бы отказ доступа. В Squid реализовать такой метод авторизации можно с помощью basic_ncsa_auth.

При данном методе авторизации имя пользователя и пароль будут хранится в текстовом файле. Логин и пароль будем создавать при помощи утилиты htpasswd входящую в состав apache-utils. Пароли будут хранится в хешированном виде.

Итак все действия ниже я буду производить на Ubuntu server 14.04.5 x64 с установленным Squid 3.5.19 по данной статье.

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

 

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

 

Осуществлять ротацию логов мы будем с помощью системной службы logrotate.

[stextbox id=’info’]Ротация логов осуществляет периодическую замену старых логов новыми, помещая устаревшие данные в архив или просто удаляя их. В зависимости от настроек архив логов может храниться как в сжатом, так и в несжатом виде и иметь необходимую глубину.[/stextbox]

 

Основные настройки logrotate хранятся в /etc/logrotate.conf, настройки отдельных сервисов (в нашем случае Squid) хранятся в /etc/logrotate.d/squid, и эти настройки имеют приоритет над logrotate.conf. Сама служба вызывается раз в сутки через планировщик cron.

Разберем как настроить связь Squid 3.5 c Active Directory через kerberos авторизацию, чтобы доступ в интернет предоставлялся только по доменным учетным записям, а так же возможность использования Active Directory групп для разграничения прав доступа в интернет.

 

 

Исходные данные:

  • Установленный на Ubuntu 14.04 Trusty Tahr (srv-squid-s) Squid 3.5
  • Домен контроллер SRV-DC1 (testzone.local) на базе Windows Server 2008 R2

 

Подготовка системы Ubuntu 14.04 Trusty Tahr (srv-squid-s)

Укажем корректное имя системы для работы с Active Directory. В файле (/etc/hostname) дописываем к имени системы название вашего домена (в моем случае я дописываю .testzone.local):

srv-squid-s.testzone.local

В файле (/etc/hosts) под записью «127.0.0.1 localhost» прописываем данные нашей системы:

192.168.1.5 srv-squid-s.testzone.local srv-squid-s

Для применения изменений перезагрузим систему:

sudo reboot

В этой статье мы разобрали как развернуть прокси-сервер Squid 3.5.19 на Ubuntu 14.04 Trusty Tahr . В этой статье мы разберем как развернуть анализатор логов прокси-сервера Squid и просмотр сформированных с помощью Sarg логов в удобном для нас виде через Web браузер.

 

Разворачивать я буду Sarg на той же машине где и стоит Squid, ОС используемая Ubuntu 14.04 Trusty Tahr. Устанавливать Sarg будем из репозитариев Ubuntu. На момент написания статьи в репозитария доступна 2.3.6 версия Sarg.

 

Первым делом обновляем систему до актуального состояния

sudo apt-get update && sudo apt-get upgrade

 

Устанавливаем Sarg

sudo apt-get install sarg

 

После установки выполним конфигурацию Sarg. Выполним резервное копирование файла конфигурации.

sudo cp /etc/sarg/sarg.conf /etc/sarg/sarg.conf.backup

Появилась необходимость на работе анализировать трафик интернета, с возможностью выставлять всякого рода запреты на пользование интернета сотрудникам и посещении сайтов как по HTTP протоколу, так и по HTTPS. Использовать будем для всех этих дел Squid 3.5.19 и развернут он будет на Ubuntu 14.04.5 LTS.

Первым делом обновляем систему до актуального состояния

sudo apt-get update
sudo apt-get upgrade

Устанавливаем необходимые для сборки пакетов инструменты

sudo apt-get -y install devscripts build-essential fakeroot debhelper dh-autoreconf cdbs

Устанавливаем зависимости для libecap и squid

sudo apt-get -y build-dep libecap
sudo apt-get -y build-dep squid3