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

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

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

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

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

Второе — это, конечно, прямая экономия интернет-канала. Представьте: всего один сотрудник, забывший выключить автоплей на YouTube, за 8 часов может 'съесть' 6–8 ГБ трафика. А в офисе, где трудится сотня человек, таких 'автоплеев' наберётся по 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 как на наш основной стандарт для всей серверной инфраструктуры. Почему? Всё просто: это стабильность, очень длинный 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 на все клиентские машины.

Базовый конфиг Squid, который мы кладём клиентам:

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+ ПК.