Корпоративный Squid-прокси: контроль интернета для офиса от АйТи Фреш

Меня зовут Семёнов Евгений Сергеевич, я директор АйТи Фреш. Чаще всего вопрос «нужен ли нам прокси» задают руководители на встрече первый раз, когда я рассказываю про информационную безопасность. Услышав «прокси» большинство представляет что-то из 2008 года, когда системные администраторы блокировали ВКонтакте, чтобы продавцы работали. Реальность 2026 года совершенно другая: корпоративный Squid — это сразу контроль трафика по требованиям ФЗ-187, экономия каналов, защита от вредоносных сайтов и инструмент расследования инцидентов. В этой статье разберу, как мы в АйТи Фреш разворачиваем такой Squid под ключ.

Почему вернулась тема корпоративных прокси

Лет десять назад прокси-серверы стояли почти в каждом приличном офисе. Потом наступила эпоха SaaS, всё ушло в облака, трафик стал HTTPS, и казалось, что Squid и его собратья превращаются в музейный экспонат. Однако за последние три года мы видим обратную тенденцию.

Во-первых, требования регуляторов. ФЗ-187 о критической инфраструктуре, требования ФСТЭК для коммерческих организаций, обязанность хранить логи интернет-активности сотрудников — без прокси выполнить это технически невозможно. NGFW от Cisco / Fortinet / Palo Alto делают то же самое, но стоят от 600 000 рублей за младшую модель. Squid делает 80 % того же за 0 рублей лицензий.

Во-вторых, экономия каналов. Один сотрудник, оставивший автоплей YouTube на 8 часов, съедает 6–8 ГБ. В офисе на 100 человек таких автоплеев бывает по 15–20 в день. Если у вас канал 100 Мбит/с, это значит, что ваши сейлзы тормозят при работе с CRM, потому что в соседнем кабинете кто-то посмотрел сериал.

В-третьих, расследование инцидентов. Бухгалтер открыл фишинговое письмо, скачал «акт сверки» с вирусом — кто, когда, откуда. Без прокси-логов вы не разберётесь, кто заразил машину и какие данные могли утечь.

Squid или коммерческое решение: матрица выбора

Мы в АйТи Фреш в 80 % случаев ставим клиентам именно Squid. Причина простая: для типового коммерческого офиса (не объект КИИ) функционала хватает, экономия на лицензиях за пять лет составляет 600–900 тысяч рублей, и при наличии аутсорсинговой поддержки сложность не имеет значения.

Архитектура: где ставим прокси и как пускаем трафик

Есть три стандартных топологии, которые работают для офиса:

1. Explicit proxy через WPAD. На сетевой шлюз клиенты ходят напрямую, но в браузере (через политику AD) прописан прокси-сервер. Так мы делаем чаще всего — это даёт аутентификацию по логину пользователя.
2. Transparent proxy. Шлюз перенаправляет весь HTTP/HTTPS-трафик на Squid через iptables. Минус: нет аутентификации (только по IP), часть HTTPS-сайтов ломается.
3. Inline на шлюзе. Squid стоит на самом шлюзе, обычно вместе с pfSense / OPNsense. Удобно для маленьких офисов, но не масштабируется.

Для офиса 50–200 человек оптимально вариант 1: explicit proxy + WPAD-файл, выдаваемый через DNS и DHCP, аутентификация по AD, настройка распространяется через GPO. Это даёт максимум возможностей и минимум проблем с совместимостью.

Установка Squid на Debian 12

Мы перешли на Debian 12 как стандарт для serverside-инфраструктуры два года назад. Стабильность, длинный LTS-цикл, минимальный набор зависимостей. Для Squid берём свежую версию из бэкпортов.

# Установка Squid и зависимостей
apt update
apt install -y squid squidguard ldap-utils sarg apache2

# Базовая проверка
squid -v
# Squid Cache: Version 6.x
# Configure options:  --enable-ssl-crtd --with-openssl ...

# Структура каталогов
mkdir -p /etc/squid/acl
mkdir -p /var/spool/squid
mkdir -p /var/log/squid
chown -R proxy:proxy /var/spool/squid /var/log/squid

# Инициализация кэша
squid -z

systemctl enable --now squid

Обращу внимание: в современных условиях кэширование HTTPS почти бесполезно, поэтому большой кэш (старые рекомендации «50 ГБ на пользователя») — устаревший подход. Хватает 5–10 ГБ для статики.

ACL: трёхуровневая система доступа по отделам

Главное в корпоративном Squid — правильная архитектура ACL. Мы используем трёхуровневую модель: сначала идентификация (по сети или AD-группе), потом категория сайта, потом время суток.

# /etc/squid/squid.conf — базовая структура

# === 1. Сети по отделам ===
acl net_accounting   src 10.10.10.0/24
acl net_dev          src 10.10.20.0/24
acl net_sales        src 10.10.30.0/24
acl net_management   src 10.10.40.0/24
acl net_office       src 10.10.0.0/16

# === 2. Категории сайтов (списки доменов в файлах) ===
acl cat_social       dstdomain "/etc/squid/acl/social.txt"
acl cat_video        dstdomain "/etc/squid/acl/video.txt"
acl cat_torrent      dstdomain "/etc/squid/acl/torrent.txt"
acl cat_malware      dstdomain "/etc/squid/acl/malware.txt"
acl cat_adult        dstdomain "/etc/squid/acl/adult.txt"

# === 3. Белый список (всегда разрешено) ===
acl wl_business      dstdomain "/etc/squid/acl/whitelist.txt"

# === 4. Время ===
acl t_workhours      time MTWHF 09:00-18:00
acl t_lunch          time MTWHF 12:30-13:30

# === 5. Типы файлов и размеры ===
acl big_downloads    rep_mime_type ^application/(octet-stream|x-msdownload)
acl ext_archives     urlpath_regex -i \.(zip|rar|7z|iso|exe|msi)$

# === Правила ===
# Вредоносные сайты — блокировка для всех без исключений
http_access deny cat_malware
http_access deny cat_adult

# Белый список (ФНС, госуслуги, банки) — разрешён всегда
http_access allow wl_business

# Руководство — без ограничений
http_access allow net_management

# Бухгалтерия — соцсети и видео всегда заблокированы
http_access deny net_accounting cat_social
http_access deny net_accounting cat_video

# Продажи — видео заблокировано в рабочее время
http_access deny net_sales cat_video t_workhours

# Разработчики — соцсети заблокированы кроме обеда
http_access allow net_dev cat_social t_lunch
http_access deny net_dev cat_social t_workhours

# Торренты — заблокированы для всех
http_access deny net_office cat_torrent

# Разрешить остальной офисный трафик
http_access allow net_office

# По умолчанию — блок
http_access deny all

Файлы со списками сайтов:

# /etc/squid/acl/social.txt
.vk.com
.ok.ru
.facebook.com
.instagram.com
.tiktok.com
.x.com
.twitter.com

# /etc/squid/acl/video.txt
.youtube.com
.youtu.be
.rutube.ru
.dzen.ru
.twitch.tv

# /etc/squid/acl/whitelist.txt
.gosuslugi.ru
.nalog.ru
.cbr.ru
.consultant.ru
.garant.ru
.1c.ru
.kontur.ru

Аутентификация через Active Directory

Аутентификация по IP-подсети работает, пока у вас один кабинет на отдел. В реальности люди ходят с ноутбуками, садятся за чужие компьютеры, подключаются к корпоративному Wi-Fi с телефонов. Поэтому для серьёзного офиса мы всегда настраиваем AD-аутентификацию.

# /etc/squid/squid.conf — Basic LDAP против AD

auth_param basic program /usr/lib/squid/basic_ldap_auth \
  -R \
  -b "dc=corp,dc=company,dc=local" \
  -D "cn=svc-squid,ou=Service Accounts,dc=corp,dc=company,dc=local" \
  -W /etc/squid/ldap_password \
  -f "(&(objectClass=user)(sAMAccountName=%s))" \
  -h dc01.corp.company.local

auth_param basic children 20 startup=5 idle=5
auth_param basic realm "Корпоративный прокси АйТи Фреш"
auth_param basic credentialsttl 2 hours

acl authenticated proxy_auth REQUIRED

# Пример: разрешаем только аутентифицированным
http_access deny !authenticated
http_access allow authenticated

Для прозрачной аутентификации без ввода пароля (single sign-on) используем Kerberos:

# Установка зависимостей
apt install -y krb5-user msktutil

# Создание keytab для squid в AD
msktutil --create --service HTTP/proxy.corp.company.local \
  --upn HTTP/proxy.corp.company.local \
  --keytab /etc/squid/proxy.keytab \
  --computer-name PROXY-SRV \
  --enctypes 0x18

chown proxy:proxy /etc/squid/proxy.keytab
chmod 600 /etc/squid/proxy.keytab

# squid.conf — Kerberos auth
auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth \
  -k /etc/squid/proxy.keytab \
  -s HTTP/proxy.corp.company.local

auth_param negotiate children 20 startup=5 idle=5
auth_param negotiate keep_alive on

Kerberos даёт принципиально другой пользовательский опыт: сотрудник один раз логинится в Windows и больше нигде не вводит пароли. Браузеры (Edge, Chrome, Firefox с правильной настройкой) берут билет Kerberos автоматически.

Правила по AD-группам

Самое мощное в связке Squid + AD — назначение прав по группам, а не по сетям. Создаёте в AD группу «Proxy-Marketing-Full», заполняете её людьми, и эта группа имеет полный доступ. А дальше можно тасовать сотрудников между группами без перенастройки прокси.

# squid.conf — проверка членства в AD-группах
external_acl_type ad_group %LOGIN /usr/lib/squid/ext_kerberos_ldap_group_acl \
  -g "%a@CORP.COMPANY.LOCAL" \
  -D CORP.COMPANY.LOCAL \
  -N CORP

acl grp_admins         external ad_group "Proxy-Admins-Full"
acl grp_marketing      external ad_group "Proxy-Marketing-Full"
acl grp_finance        external ad_group "Proxy-Finance-Restricted"
acl grp_default        external ad_group "Proxy-Default"

# Полный доступ для админов и маркетинга
http_access allow grp_admins
http_access allow grp_marketing

# Для финансов блокируем соцсети и видео
http_access deny grp_finance cat_social
http_access deny grp_finance cat_video
http_access allow grp_finance

# Дефолтная политика
http_access allow grp_default
http_access deny all

Распространение настроек через GPO

Каждый администратор знает: ходить по 130 рабочим местам и настраивать прокси в браузере вручную — это плохой план. Делаем через групповые политики.

# На контроллере домена в Group Policy Management:

# 1. Computer Configuration → Preferences → Windows Settings →
#    Registry → New → Registry Item:
#    Hive: HKEY_CURRENT_USER
#    Key: Software\Microsoft\Windows\CurrentVersion\Internet Settings
#    Value name: ProxyEnable
#    Value type: REG_DWORD
#    Value data: 1

#    То же для ProxyServer = "proxy.corp.company.local:3128"
#    То же для ProxyOverride = "<local>;*.corp.company.local;10.10.*"

# 2. Для Chrome/Edge — отдельная политика:
#    Computer Configuration → Administrative Templates →
#    Google → Google Chrome → ProxySettings:
#    "ProxyMode": "fixed_servers"
#    "ProxyServer": "proxy.corp.company.local:3128"
#    "ProxyBypassList": "*.corp.company.local"

Альтернатива GPO — WPAD-файл, который раздаётся через DHCP и DNS:

# /var/www/html/wpad.dat
function FindProxyForURL(url, host) {
    if (isInNet(host, "10.10.0.0", "255.255.0.0") ||
        isInNet(host, "192.168.0.0", "255.255.0.0") ||
        host == "localhost" || dnsDomainIs(host, ".corp.company.local")) {
        return "DIRECT";
    }
    return "PROXY proxy.corp.company.local:3128; DIRECT";
}

# В DNS добавляем запись:
# wpad.corp.company.local. IN A 10.10.1.20

# В DHCP-сервере добавляем опцию 252:
# option 252 = "http://wpad.corp.company.local/wpad.dat"

SSL Bump: когда нужно и как делать правильно

SSL Bump — это перехват HTTPS-трафика. Squid выступает посредником: для клиента он представляется youtube.com, а сам ходит к настоящему youtube.com от своего имени. Это позволяет видеть полный URL, но требует установки корневого сертификата Squid на все клиентские машины.

Перед внедрением SSL Bump обязательно:

1. Согласовать с юристом и подписать с сотрудниками уведомление о мониторинге (ст. 86 ТК РФ, ФЗ-152).
2. Составить список «исключений» — банки, госуслуги, медицинские порталы, личные сервисы. Их перехватывать нельзя.
3. Подготовить процедуру срочного отключения SSL Bump на случай проблем с конкретными приложениями.

# Генерация корневого CA для Squid
mkdir -p /etc/squid/ssl
cd /etc/squid/ssl

openssl req -new -newkey rsa:4096 -sha256 -days 3650 -nodes \
  -x509 -keyout squid-ca.pem -out squid-ca.pem \
  -subj "/C=RU/ST=Moscow/O=Company/OU=IT/CN=Company Proxy CA"

# Конвертация для Windows
openssl x509 -in squid-ca.pem -outform DER -out squid-ca.der

# База сертификатов для динамической генерации
/usr/lib/squid/security_file_certgen -c -s /var/spool/squid/ssl_db -M 64MB
chown -R proxy:proxy /var/spool/squid/ssl_db

# squid.conf
http_port 3128 ssl-bump \
  cert=/etc/squid/ssl/squid-ca.pem \
  generate-host-certificates=on \
  dynamic_cert_mem_cache_size=16MB

sslcrtd_program /usr/lib/squid/security_file_certgen \
  -s /var/spool/squid/ssl_db -M 64MB
sslcrtd_children 8 startup=2 idle=2

# Список «не перехватываем» — банки, госы, мессенджеры
acl no_bump_list ssl::server_name "/etc/squid/acl/nobump.txt"

ssl_bump peek step1 all
ssl_bump splice no_bump_list
ssl_bump bump all

# /etc/squid/acl/nobump.txt
.sberbank.ru
.tinkoff.ru
.vtb.ru
.alfabank.ru
.gazprombank.ru
.nalog.ru
.gosuslugi.ru
.mos.ru
.cbr.ru
.t.me
.telegram.org

Распространение CA на Windows-клиентов делаем через GPO: Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities → Import.

Delay pools: ограничение скорости для скачиваний

Один сотрудник, скачивающий 8-гигабайтный ISO Windows Server в три часа дня, способен положить весь офисный канал. Delay pools решают эту проблему.

# squid.conf — два пула с разными лимитами

delay_pools 2

# Пул 1: общий лимит на скачивание больших файлов
delay_class 1 2
# Параметры: общая скорость / на пользователя
# 50 Мбит/с = 6 250 000 байт/с
# 1 Мбит/с = 125 000 байт/с
delay_parameters 1 6250000/6250000 125000/250000
delay_access 1 allow ext_archives net_office
delay_access 1 deny all

# Пул 2: видео-трафик
delay_class 2 2
delay_parameters 2 3125000/3125000 64000/128000
acl streaming dstdomain .youtube.com .rutube.ru .vimeo.com
delay_access 2 allow streaming net_office
delay_access 2 deny all

Логирование и отчёты через SARG

Сами логи Squid читать невозможно — это сотни мегабайт сырого текста. SARG (Squid Analysis Report Generator) превращает их в нормальные HTML-отчёты с разбивкой по пользователям, сайтам и времени.

# Установка
apt install -y sarg

# Конфигурация /etc/sarg/sarg.conf
access_log /var/log/squid/access.log
output_dir /var/www/html/sarg
date_format e
charset UTF-8
language Russian
title "Корпоративный прокси — отчёты"
overwrite_report yes
report_type topusers topsites users_sites sites_users \
  date_time denied auth_failures site_user_time_date downloads
exclude_users none
top_sites_num 100

# Cron для генерации отчётов
cat > /etc/cron.d/sarg <<'EOF'
# Дневной отчёт каждый день в 23:55
55 23 * * * root /usr/bin/sarg -d $(date +\%d/\%m/\%Y) -o /var/www/html/sarg/daily

# Недельный отчёт по понедельникам
0 4 * * 1 root /usr/bin/sarg -d $(date -d "1 week ago" +\%d/\%m/\%Y)-$(date +\%d/\%m/\%Y) -o /var/www/html/sarg/weekly

# Месячный отчёт первого числа
0 5 1 * * root /usr/bin/sarg -d $(date -d "1 month ago" +\%d/\%m/\%Y)-$(date +\%d/\%m/\%Y) -o /var/www/html/sarg/monthly
EOF

Доступ к отчётам — через Apache с базовой аутентификацией:

# /etc/apache2/sites-available/sarg.conf
<VirtualHost *:443>
    ServerName proxy-reports.corp.company.local
    DocumentRoot /var/www/html/sarg

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/proxy-reports.corp.company.local/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/proxy-reports.corp.company.local/privkey.pem

    <Directory /var/www/html/sarg>
        AuthType Basic
        AuthName "Proxy Reports"
        AuthUserFile /etc/apache2/sarg-users
        Require valid-user
    </Directory>
</VirtualHost>

Реальный кейс: 130 человек, оптовая торговля, апрель 2025

Клиент пришёл с понятной болью: канал 200 Мбит/с регулярно забит на 100 %, ИБ-аудитор по внешнему контракту требует логи интернет-активности за полгода, а в начале месяца на бухгалтера попал шифровальщик через файл, скачанный с какого-то «полезного» сайта. Бухгалтерская база восстановилась из бэкапа, но 4 часа простоя стоили компании сделок на 1.7 млн рублей.

За 3 рабочих дня мы развернули у них Squid 6.x на отдельной виртуалке (Debian 12, 4 vCPU, 8 ГБ RAM, 100 ГБ SSD). Базовая конфигурация: ACL по 4 отделам с привязкой к AD-группам, Kerberos-аутентификация со SSO, фильтрация по 7 категориям (соцсети, видео, торренты, гэмблинг, adult, malware, новости), белый список из 40 деловых сайтов. Развёртывание SARG, ежедневные отчёты на корпоративный портал. Через WPAD и GPO распространили настройки на 130 рабочих мест за полтора часа.

Через месяц замерили эффект:

• Загрузка канала в пиковые часы упала со 100 % до 60–65 %.
• Заблокировано 4 200 обращений к фишинговым/малвар-доменам.
• Среднее время отклика CRM (1С) упало с 3.2 с до 1.1 с.
• ИБ-отчёт по требованию аудитора был сгенерирован за 15 минут вместо двух недель «откуда мы возьмём эти данные».

Стоимость работ: 95 000 ₽ единовременно, 7 500 ₽/мес на сопровождение в рамках абонентского обслуживания. Окупилось это за один несостоявшийся инцидент с шифровальщиком.

Юридическая сторона: уведомление сотрудников

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

Без этих документов любой уволенный сотрудник может подать в суд за нарушение тайны переписки (ст. 23 Конституции РФ) и выиграть. С документами — мониторинг полностью законен и соответствует ТК РФ.

FAQ — частые вопросы по корпоративному прокси

Зачем офису прокси-сервер в 2026 году?

Три причины: контроль интернет-трафика (требование ИБ и ФЗ-187), экономия каналов, защита от вредоносных сайтов. Для офисов 50+ человек — полностью окупается за счёт повышения производительности и снижения инцидентов.

Можно ли поставить Squid без HTTPS-инспекции?

Да. Без SSL Bump прокси видит только домен (например, youtube.com), но не URL внутри. Этого хватает для блокировки целых сайтов. SSL Bump нужен только если нужно блокировать конкретные разделы (например, разрешить рабочие YouTube-каналы и заблокировать развлечения).

Что лучше — Squid или коммерческие решения вроде Kerio?

Squid дешевле по лицензиям (бесплатен), гибче в настройке, но требует Linux-инженера для сопровождения. Kerio Control / UserGate — дороже (от 80 000 ₽/год за 50 пользователей), проще в управлении через GUI. Для офисов с системным администратором мы рекомендуем Squid.

Как сотрудники узнают, что их трафик логируется?

Обязательно нужно подписать с каждым сотрудником уведомление о мониторинге интернет-трафика — это требование Трудового кодекса (ст. 86) и ФЗ-152. АйТи Фреш помогает с шаблонами документов при внедрении прокси.

Сколько стоит внедрение Squid под ключ?

Базовое развёртывание для офиса до 50 ПК — от 45 000 ₽: установка, ACL по отделам, AD-аутентификация, отчёты SARG. Полный комплект с SSL Bump, GPO для распространения сертификата и распределением политик по AD-группам — от 90 000 ₽ для офиса 100+ ПК.