🌐 Сети и связь📅 31.03.2026⏱️ 20 мин чтения✍️ АйТи Фреш
YouTube съедал весь канал: настраиваем Squid-прокси для рекламного агентства
Задача клиента: рекламное агентство без контроля над трафиком
Летом 2025 года к нам в АйТи Фреш обратилось рекламное агентство BrightMedia из Санкт-Петербурга. 42 человека в штате: дизайнеры, копирайтеры, менеджеры, бухгалтерия. Оптика на 200 Мбит/с — канал, которого должно было хватать с запасом.
Но в рабочие часы интернет еле дышал. Видеоконференции с клиентами рвались на полуслове, макеты на сервер ползли по несколько минут, CRM регулярно падала в таймаут. Руководство чувствовало, что канал сливается впустую, — только доказать это было нечем.
Мы не стали гадать. Поставили зеркалирование порта на коммутаторе, три дня собирали данные через ntopng — и картина стала абсолютно прозрачной:
42% трафика — YouTube (фоновые видео, music mix на рабочих местах)
18% — социальные сети (Instagram, TikTok, VK видео)
12% — Telegram-каналы (стикерпаки, видео в чатах)
28% — рабочий трафик (CRM, почта, облачные хранилища, видеосвязь)
Итого: 72% канала уходило мимо работы. Причём просто заблокировать YouTube и соцсети не получалось — дизайнеры и SMM-специалисты работали с ними напрямую, по задачам клиентов. Рубить сплеча нельзя.
«Мне не нужна тюрьма. Мне нужна прозрачность и разумные ограничения» — директор BrightMedia.
Требования к решению
Вместе с клиентом сели и сформулировали, что конкретно нужно:
Ограничить скорость видеостриминга для всех, кроме отдела SMM и дизайна
Решение не должно стоить как корпоративный UTM-файрвол
Мы предложили связку Squid + SquidGuard + SARG на отдельном сервере под Ubuntu 22.04 LTS. Железо — один сервер за 45 000 ₽. Весь софт — бесплатный. Для задач агентства этого оказалось более чем достаточно.
Установка и базовая настройка Squid
Squid развернули на выделенном сервере с двумя сетевыми интерфейсами: один смотрит в локальную сеть офиса (192.168.10.0/24), второй — в WAN. Классическая схема, работающая без сюрпризов.
Установка из пакетов Ubuntu
# Обновляем систему
sudo apt update && sudo apt upgrade -y
# Устанавливаем Squid и вспомогательные пакеты
sudo apt install -y squid squid-openssl squidguard \
apache2-utils sarg lightsquid
# Проверяем версию
squid -v | head -3
# Squid Cache: Version 5.7
# Service Name: squid
# configure options: '--with-openssl' ...
# Делаем бэкап оригинального конфига
sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.bak
Основная конфигурация squid.conf
Конфигурацию писали с нуля — разбили на логические блоки, чтобы потом не искать нужную строчку в полотне текста:
# /etc/squid/squid.conf
# === СЕТЕВЫЕ НАСТРОЙКИ ===
http_port 3128
http_port 3129 intercept # для прозрачного проксирования
https_port 3130 intercept ssl-bump \
cert=/etc/squid/ssl/squid-ca.pem \
generate-host-certificates=on \
dynamic_cert_mem_cache_size=16MB
# === КЭШИРОВАНИЕ ===
cache_mem 512 MB
maximum_object_size_in_memory 2 MB
maximum_object_size 256 MB
cache_dir ufs /var/spool/squid 10000 16 256
cache_replacement_policy heap LFUDA
memory_replacement_policy heap GDSF
# === DNS ===
dns_nameservers 192.168.10.1 8.8.8.8
positive_dns_ttl 6 hours
negative_dns_ttl 1 minute
# === ЛОГИРОВАНИЕ ===
access_log daemon:/var/log/squid/access.log squid
cache_log /var/log/squid/cache.log
logfile_rotate 30
# === АУТЕНТИФИКАЦИЯ (LDAP через AD) ===
auth_param basic program /usr/lib/squid/basic_ldap_auth \
-v 3 -R -b "DC=brightmedia,DC=local" \
-D "CN=squid-bind,OU=Service Accounts,DC=brightmedia,DC=local" \
-w "${LDAP_BIND_PASSWORD}" \
-f "(&(sAMAccountName=%s)(objectClass=person))" \
-h dc01.brightmedia.local
auth_param basic children 10 startup=3 idle=3
auth_param basic realm BrightMedia Proxy
auth_param basic credentialsttl 2 hours
# Внешний хелпер для получения LDAP-групп
external_acl_type ldap_group ttl=300 %LOGIN \
/usr/lib/squid/ext_ldap_group_acl \
-v 3 -R -b "DC=brightmedia,DC=local" \
-D "CN=squid-bind,OU=Service Accounts,DC=brightmedia,DC=local" \
-w "${LDAP_BIND_PASSWORD}" \
-f "(&(sAMAccountName=%u)(memberOf=CN=%g,OU=Groups,DC=brightmedia,DC=local))" \
-h dc01.brightmedia.local
# === ACL ОПРЕДЕЛЕНИЯ ===
acl authenticated proxy_auth REQUIRED
# Группы из AD
acl group_smm external ldap_group SMM-Department
acl group_design external ldap_group Design-Department
acl group_management external ldap_group Management
acl group_accounting external ldap_group Accounting
# Сети
acl localnet src 192.168.10.0/24
acl SSL_ports port 443
acl Safe_ports port 80 443 21 70 210 280 488 591 777 1025-65535
# Рабочее время
acl work_hours time MTWHF 09:00-18:00
acl lunch_time time MTWHF 12:00-13:00
# Категории сайтов (подробнее — в секции SquidGuard)
acl streaming_sites dstdomain .youtube.com .googlevideo.com .ytimg.com
acl streaming_sites dstdomain .tiktok.com .musical.ly .tiktokcdn.com
acl social_media dstdomain .instagram.com .cdninstagram.com
acl social_media dstdomain .vk.com .vk.me .userapi.com
acl social_media dstdomain .facebook.com .fbcdn.net
acl business_critical dstdomain .bitrix24.ru .amocrm.ru .zoom.us
acl business_critical dstdomain .googleapis.com .gstatic.com
# === SSL BUMP ===
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump bump all
sslcrtd_program /usr/lib/squid/security_file_certgen \
-s /var/lib/squid/ssl_db -M 16MB
# === ПРАВИЛА ДОСТУПА ===
# Запрет небезопасных портов
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
# Бизнес-критичные ресурсы — без ограничений для всех
http_access allow localnet business_critical
# SMM и дизайн — полный доступ к стримингу и соцсетям
http_access allow group_smm streaming_sites
http_access allow group_smm social_media
http_access allow group_design streaming_sites
http_access allow group_design social_media
# В обед — стриминг доступен всем
http_access allow authenticated streaming_sites lunch_time
http_access allow authenticated social_media lunch_time
# В рабочее время — стриминг ограничен для остальных
http_access deny streaming_sites work_hours
# Аутентифицированные пользователи — всё остальное
http_access allow authenticated
# Запрет всего остального
http_access deny all
Генерация SSL-сертификата для HTTPS-инспекции
Чтобы фильтровать HTTPS-трафик, Squid делает SSL Bump — перехватывает TLS-соединения и подменяет сертификаты. Без этого вы видите только IP-адреса, а не реальные сайты. Соответственно, корневой CA-сертификат нужно разложить на все рабочие станции:
# Создаём директорию для сертификатов
sudo mkdir -p /etc/squid/ssl
cd /etc/squid/ssl
# Генерируем корневой CA-сертификат (срок 10 лет)
sudo openssl req -new -newkey rsa:4096 -sha256 -days 3650 \
-nodes -x509 \
-keyout squid-ca.pem \
-out squid-ca.pem \
-subj "/C=RU/ST=SPb/L=Saint-Petersburg/O=BrightMedia/CN=BrightMedia Proxy CA"
# Экспортируем сертификат в формате DER для Windows-клиентов
sudo openssl x509 -in squid-ca.pem -outform DER -out squid-ca.der
# Инициализируем базу SSL-сертификатов
sudo /usr/lib/squid/security_file_certgen -c -s /var/lib/squid/ssl_db -M 16MB
sudo chown -R proxy:proxy /var/lib/squid/ssl_db
# Распространяем сертификат через GPO Active Directory
# Файл squid-ca.der загружается в:
# Computer Configuration → Policies → Windows Settings →
# Security Settings → Public Key Policies → Trusted Root CAs
Для Linux-клиентов (у дизайнеров были рабочие станции на Ubuntu):
В донорской статье упоминается, что последние два года стандартом для серверной инфраструктуры в «АйТи Фреш» является Debian 12. Причины — стабильность, длинный LTS-цикл и минимум лишних зависимостей. Если вы не привязаны к Ubuntu, Debian 12 — отличный выбор для прокси-сервера.
При этом Squid рекомендуется ставить самой свежей версии из бэкпортов, чтобы получить актуальные возможности фильтрации и производительность.
Важное замечание по кэшу: в современных условиях кэширование HTTPS почти бесполезно, поэтому большой кэш (старые рекомендации «50 ГБ на пользователя») — устаревший подход. Хватает 5–10 ГБ для статики.
LDAP-аутентификация через Active Directory
В BrightMedia весь офис работал в доменной среде Windows. Мы подключили аутентификацию Squid через Active Directory — люди заходили под своими доменными учётками, никаких дополнительных паролей вводить не нужно.
Создание сервисной учётной записи
В Active Directory завели отдельную учётку с минимальными правами — только для чтения, ничего лишнего:
Базовая LDAP-аутентификация требует от пользователя вводить логин и пароль при каждом открытии браузера. Для прозрачной аутентификации без ввода пароля (single sign-on) используется Kerberos: сотрудник один раз логинится в Windows, и браузеры (Edge, Chrome, Firefox с правильной настройкой) берут билет 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
Для проверки членства в AD-группах при Kerberos-аутентификации используется отдельный хелпер:
Полная блокировка стриминга в рекламном агентстве — это нереально. Поэтому мы пошли другим путём: delay pools в Squid дают «мягкое» ограничение скорости именно для потокового видео, не трогая всё остальное.
Конфигурация delay pools
# Добавляем в squid.conf
# === DELAY POOLS (ограничение скорости) ===
# Pool 1: стриминговый трафик для обычных сотрудников
# Class 2: общий лимит + per-host лимит
delay_pools 2
# Pool 1: YouTube/TikTok для не-SMM/не-дизайнеров
delay_class 1 2
# Aggregate: 10 Мбит/с на весь пул, per-host: 2 Мбит/с
delay_parameters 1 1250000/2500000 250000/500000
delay_access 1 deny group_smm
delay_access 1 deny group_design
delay_access 1 allow streaming_sites
delay_access 1 deny all
# Pool 2: общий лимит для соцсетей (кроме SMM)
delay_class 2 2
# Aggregate: 20 Мбит/с, per-host: 5 Мбит/с
delay_parameters 2 2500000/5000000 625000/1250000
delay_access 2 deny group_smm
delay_access 2 deny group_design
delay_access 2 allow social_media
delay_access 2 deny all
Параметры delay_parameters задаются в байтах/сек в формате restore/maximum. Расшифровываю:
Пул 1: общий лимит стриминга — 10 Мбит/с (1 250 000 байт/с), на одного пользователя — 2 Мбит/с. Хватает на YouTube 480p, но о 4K можно забыть
Пул 2: общий лимит соцсетей — 20 Мбит/с, на пользователя — 5 Мбит/с. Фото открываются нормально, массовая загрузка видео — тормозится
QoS и приоритизация бизнес-трафика на уровне iptables
Параллельно настроили приоритизацию трафика на уровне ОС — через tc и iptables:
#!/bin/bash
# /etc/squid/scripts/traffic-shaping.sh
# Интерфейс в WAN
WAN_IF="ens192"
TOTAL_BW="200mbit"
# Удаляем старые правила
tc qdisc del dev $WAN_IF root 2>/dev/null
# Создаём корневой HTB
tc qdisc add dev $WAN_IF root handle 1: htb default 30
tc class add dev $WAN_IF parent 1: classid 1:1 htb rate $TOTAL_BW
# Класс 1:10 — бизнес-критичный трафик (гарантия 100 Мбит)
tc class add dev $WAN_IF parent 1:1 classid 1:10 htb \
rate 100mbit ceil 200mbit prio 1
# Класс 1:20 — обычный веб (гарантия 60 Мбит)
tc class add dev $WAN_IF parent 1:1 classid 1:20 htb \
rate 60mbit ceil 180mbit prio 2
# Класс 1:30 — стриминг и соцсети (гарантия 40 Мбит, потолок 80)
tc class add dev $WAN_IF parent 1:1 classid 1:30 htb \
rate 40mbit ceil 80mbit prio 3
# Маркировка через iptables (Squid помечает пакеты через MARK)
iptables -t mangle -A OUTPUT -m mark --mark 10 -j CLASSIFY --set-class 1:10
iptables -t mangle -A OUTPUT -m mark --mark 20 -j CLASSIFY --set-class 1:20
iptables -t mangle -A OUTPUT -m mark --mark 30 -j CLASSIFY --set-class 1:30
В конфигурацию Squid добавили маркировку пакетов:
# В squid.conf — маркировка TCP-пакетов
tcp_outgoing_mark 0x0a business_critical
tcp_outgoing_mark 0x1e streaming_sites
tcp_outgoing_mark 0x14 all
SquidGuard: контентная фильтрация по категориям
Для блокировки нежелательных категорий сайтов взяли SquidGuard с бесплатными базами от Shalla и Université Toulouse. Обновляются регулярно, покрывают большинство проблемных категорий.
Установка и настройка SquidGuard
# Скачиваем списки категорий
cd /var/lib/squidguard/db
sudo wget http://dsi.ut-capitole.fr/blacklists/download/blacklists.tar.gz
sudo tar xzf blacklists.tar.gz
sudo mv blacklists/* .
sudo rm -rf blacklists blacklists.tar.gz
# Структура:
# /var/lib/squidguard/db/
# ├── adult/
# │ ├── domains
# │ └── urls
# ├── gambling/
# ├── malware/
# ├── phishing/
# ├── warez/
# └── ...
# Конфигурация SquidGuard
sudo tee /etc/squidguard/squidGuard.conf > /dev/null << 'SQEOF'
dbhome /var/lib/squidguard/db
logdir /var/log/squidguard
# Источники
src smm_team {
# IP-адреса SMM-отдела (DHCP-резервации)
ip 192.168.10.50-192.168.10.59
}
src design_team {
ip 192.168.10.60-192.168.10.74
}
src all_users {
ip 192.168.10.0/24
}
# Категории для блокировки
dest adult {
domainlist adult/domains
urllist adult/urls
log adult.log
}
dest gambling {
domainlist gambling/domains
urllist gambling/urls
log gambling.log
}
dest malware {
domainlist malware/domains
urllist malware/urls
log malware.log
}
dest phishing {
domainlist phishing/domains
urllist phishing/urls
log phishing.log
}
dest warez {
domainlist warez/domains
urllist warez/urls
log warez.log
}
# Правила
acl {
smm_team {
pass !adult !malware !phishing all
}
design_team {
pass !adult !malware !phishing all
}
all_users {
pass !adult !gambling !malware !phishing !warez all
}
default {
pass none
redirect http://proxy.brightmedia.local/blocked.html?url=%u&category=%t
}
}
SQEOF
# Компилируем базы данных
sudo squidGuard -C all
sudo chown -R proxy:proxy /var/lib/squidguard/db
Прежде чем запускать прокси с логированием и SSL-инспекцией, крайне важно подписать с каждым сотрудником два документа: уведомление о мониторинге и согласие на обработку персональных данных в части интернет-активности. Без этих документов любой уволенный сотрудник может подать в суд за нарушение тайны переписки (ст. 23 Конституции РФ) — и, скорее всего, выиграет.
Рекомендуемый порядок действий:
Согласовать с юристом и подписать с сотрудниками уведомление о мониторинге (ст. 86 ТК РФ, ФЗ-152).
Составить список «исключений» — банки, госуслуги, медицинские порталы, личные сервисы. Их перехватывать нельзя.
Подготовить процедуру срочного отключения SSL Bump на случай проблем с конкретными приложениями.
С правильно оформленными документами мониторинг абсолютно законен и полностью соответствует ТК РФ.
Отчётность: SARG и LightSquid
Контроль без отчётности — это иллюзия контроля. Настроили две системы: одну для руководства, другую для технического мониторинга.
SARG: детальные HTML-отчёты
# Конфигурация SARG
sudo tee /etc/sarg/sarg.conf > /dev/null << 'SQEOF'
access_log /var/log/squid/access.log
output_dir /var/www/sarg-reports
resolve_ip yes
user_ip no
topuser_sort_field BYTES reverse
user_sort_field BYTES reverse
date_format e
overwrite_report yes
charset UTF-8
show_successful_message no
topuser_num 20
exclude_hosts 192.168.10.1
lastlog 30
SQEOF
# Генерация отчёта за сегодня
sudo sarg -x
# Ежедневный cron
sudo tee /etc/cron.daily/sarg-reports << 'EOF'
#!/bin/bash
/usr/bin/sarg -x > /dev/null 2>&1
EOF
sudo chmod +x /etc/cron.daily/sarg-reports
SARG строил детальные отчёты: топ пользователей по трафику, конкретные сайты, время онлайн, заблокированные запросы. Всё это открывалось у руководства по адресу http://proxy.brightmedia.local/sarg-reports/ — без звонков в IT.
Чтобы не бегать по рабочим станциям с настройками, реализовали два подхода: WPAD/PAC для доменных машин и прозрачный прокси для гостевых устройств.
WPAD через DHCP и DNS
# Файл автонастройки прокси
sudo tee /var/www/proxy/wpad.dat > /dev/null << 'EOF'
function FindProxyForURL(url, host) {
// Прямой доступ к локальным ресурсам
if (isPlainHostName(host) ||
shExpMatch(host, "*.brightmedia.local") ||
isInNet(host, "192.168.0.0", "255.255.0.0") ||
isInNet(host, "10.0.0.0", "255.0.0.0")) {
return "DIRECT";
}
// Всё остальное — через прокси
return "PROXY proxy.brightmedia.local:3128; DIRECT";
}
EOF
# DNS-запись для автообнаружения
# На DNS-сервере (DC01) добавляем A-запись:
# wpad.brightmedia.local → 192.168.10.5 (IP прокси-сервера)
# DHCP-опция 252 (на DHCP-сервере Windows):
# Set-DhcpServerv4OptionValue -OptionId 252 \
# -Value "http://wpad.brightmedia.local/wpad.dat"
iptables redirect для прозрачного режима
# На шлюзе/маршрутизаторе или на самом прокси-сервере
# Перенаправляем HTTP/HTTPS трафик на Squid
# Включаем IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
# Redirect HTTP → Squid intercept port
iptables -t nat -A PREROUTING -i ens224 \
-p tcp --dport 80 \
-j REDIRECT --to-port 3129
# Redirect HTTPS → Squid SSL bump port
iptables -t nat -A PREROUTING -i ens224 \
-p tcp --dport 443 \
-j REDIRECT --to-port 3130
# Исключаем трафик от самого прокси-сервера
iptables -t nat -A OUTPUT -m owner --uid-owner proxy \
-p tcp --dport 80 -j RETURN
iptables -t nat -A OUTPUT -m owner --uid-owner proxy \
-p tcp --dport 443 -j RETURN
# Сохраняем правила
sudo apt install iptables-persistent -y
sudo netfilter-persistent save
Результаты внедрения
Уложились в 5 рабочих дней. Через месяц эксплуатации посмотрели на цифры — результат оказался лучше, чем рассчитывали:
Рабочий трафик вырос с 28% до 71% от общего объёма — канал наконец освободился для бизнес-задач
Видеоконференции перестали обрываться — jitter упал с 45 мс до 8 мс после настройки QoS. Переговоры с клиентами наконец-то шли без «квадратиков» на экране
Загрузка макетов ускорилась втрое. CRM и облачные хранилища получили приоритет по полосе — дизайнеры перестали жаловаться на «вечно крутящийся спиннер»
Ноль жалоб от SMM и дизайнеров — мы намеренно не трогали их рабочий трафик, и это решение себя оправдало
Экономия вышла существенная — сервер обошёлся в 45 000 ₽ против 350 000 ₽ за железный UTM типа FortiGate или Check Point. Функционал при этом закрыл все задачи клиента
3 инцидента ИБ предотвращены — SquidGuard заблокировал переходы на фишинговые сайты ещё до того, как пользователи успели что-то ввести
Руководство получило еженедельные отчёты по интернет-активности и смогло принимать реальные кадровые решения, опираясь на цифры, а не на ощущения. Сотрудники, кстати, восприняли систему спокойно — особенно когда узнали про «обеденный час свободы»: с 13:00 до 14:00 YouTube и соцсети открывались без ограничений.
«Наконец-то Zoom не лагает, а я вижу, куда уходит трафик. И главное — никто не жалуется!» — директор BrightMedia.
После запуска мы не бросили проект. Специалисты АйТи Фреш ведут систему на абонентском обслуживании: еженедельно обновляем списки блокировки, добавляем новые правила под изменившиеся задачи бизнеса, отслеживаем аномалии в трафике — иногда именно там первыми всплывают проблемы.
Часто задаваемые вопросы
Да, но с оговорками. Без SSL Bump Squid видит только доменное имя через SNI — конкретный URL внутри HTTPS-сессии остаётся закрытым. Заблокировать youtube.com целиком — легко. Разрешить только конкретный канал, запретив остальные — уже нет. Для большинства офисных задач блокировки по домену вполне хватает, и мы чаще всего идём именно этим путём.
При грамотной настройке влияние на скорость минимально — Squid добавляет 1–3 мс задержки на запрос, это незаметно. Более того, кэширование статики (CSS, JS, картинки) ускоряет повторные загрузки на 20–40%. В нашем кейсе пользователи субъективно почувствовали, что интернет стал быстрее — просто потому что стриминг перестал съедать канал.
Только если включён SSL Bump для инспекции HTTPS-трафика. В доменной среде Windows сертификат разъезжается по машинам через GPO автоматически — руками ничего устанавливать не надо. Если SSL Bump не используется, никакого сертификата не нужно, но фильтрация HTTPS будет работать исключительно по домену через SNI.
Мы настроили автообновление через cron — раз в неделю, в нерабочее время. Списки Université Toulouse бесплатные, регулярно пополняются и содержат миллионы доменов, разбитых по категориям. Плюс администратор в любой момент может вручную дописать нужный домен в локальный whitelist или blacklist — это буквально одна строка в файле.
Да, Squid 5.x нормально работает с современным трафиком: TLS 1.2/1.3, HTTP/2, SNI-фильтрация, SSL Bump — всё поддерживается. Единственный нюанс: приложения с certificate pinning (банковский софт и некоторые корпоративные клиенты) через SSL Bump не ходят. Для них настраиваем исключения через ssl_bump splice — и проблема снята.
#Squid прокси-сервер#настройка Squid#контроль интернета в офисе#фильтрация трафика Squid#HTTPS прокси Squid#ACL Squid настройка#Squid LDAP аутентификация#ограничение скорости интернета
Столкнулись с похожей задачей? Обращайтесь — решим
Если у вас происходит что-то из описанного в этой статье — или любая другая проблема с ИТ-инфраструктурой, — обращайтесь в любое время. Мои специалисты и я лично разберём ситуацию, найдём настоящую причину и доведём до решения.
Возьмёмся и за разовую задачу, и за постоянное обслуживание. Первичная консультация — бесплатно и без обязательств.
Каждую неделю мы выпускаем практические гайды для руководителей IT и системных администраторов. Это не просто теория! Здесь вы найдёте всё: безопасность, 1С, миграции, резервные копии и проверенные лайфхаки из наших реальных проектов.
Реквизиты оператора персональных данных
ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.