Запрет определённых сайтов по имени
Иногда нужно ограничить доступ к определённым сайтам по доменному имени: в офисе, школе, гостиничном Wi-Fi, домашней сети или на сервере, где важно снизить риски (блокировать вредоносные домены, рекламные сети или отвлекающие сервисы). “По имени” означает, что мы нацеливаемся на домен (например, example.com), а не на фиксированный IP. Это удобно, но в современной реальности HTTPS, CDN и часто меняющиеся IP делают простую блокировку по IP ненадёжной. Поэтому доменные ограничения обычно реализуют на уровне DNS или через прокси/шлюз безопасности.
Ниже рассмотрим несколько методов: hosts (самый простой локально), DNS-блокировка (лучше всего для всей сети), firewall-подходы (ограничены для HTTPS) и прокси, которые дают более точный контроль, журналы и политики. Если вам нужен централизованный контроль для многих устройств, обычно это делается на уровне маршрутизации/безопасности. Это можно построить, например, на облачном роутере MikroTik или поднять свой DNS/прокси на VPS. Для полноценного периметра безопасности с отчётами и политиками подойдут решения Fortinet.
Важно: статья предполагает, что вы ограничиваете доступ в собственной сети или на системах, которыми вы администрируете. Попытки управлять чужими устройствами/сетями без разрешения — не корректный сценарий. Примеры ниже рассчитаны на контроль конечных устройств или сетевого слоя (DNS/роутер/прокси).
1) Hosts: самый простой локальный вариант
Файл hosts позволяет локально переопределить DNS для домена. Вы указываете, что example.com “равен” 0.0.0.0 или 127.0.0.1, и браузер не сможет открыть сайт (или откроет localhost). Это быстро для одного компьютера, но плохо масштабируется: нужно править каждое устройство отдельно.
Linux: /etc/hosts, Windows: C:WindowsSystem32driversetchosts, macOS: /etc/hosts. После изменений иногда нужно очистить DNS-кеш (systemd-resolved, кеш браузера), чтобы всё применилось сразу.
# пример /etc/hosts 0.0.0.0 example.com 0.0.0.0 www.example.com
Ограничения: hosts не умеет wildcard (*.example.com) без ручного списка, а современные сервисы используют много поддоменов. Поэтому hosts — хороший “быстрый фикс”, но не корпоративная политика.
2) DNS-блокировка: лучший метод для всей сети
DNS-блокировка означает, что ваш DNS-резолвер отвечает так, чтобы домен не резолвился (NXDOMAIN) или резолвился в “нулевой” адрес. Реализуется через dnsmasq, Unbound, BIND, Pi-hole, AdGuard Home или через UTM/firewall с DNS-фильтрацией. Плюс — централизованность: меняете DNS в DHCP на роутере, и правила действуют для всех устройств.
Простой вариант dnsmasq — “прибить” домен к 0.0.0.0. Это работает, но есть обход: пользователь включает DoH/DoT (DNS over HTTPS/TLS) в браузере или приложении и уходит на публичный DNS. Если вам нужна реальная “необходимость”, надо блокировать DoH endpoint’ы, управлять устройствами политикой или использовать шлюз безопасности, который контролирует DNS-трафик.
# пример dnsmasq address=/example.com/0.0.0.0 address=/www.example.com/0.0.0.0
DNS-фильтрация отлично подходит для вредоносных доменов и рекламных списков. Она же позволяет вести статистику, белые списки и исключения. Минус — DNS не остановит доступ по прямому IP (редко) и не контролирует трафик внутри VPN.
3) Firewall и реальность HTTPS: почему “по имени” сложно на уровне IP
Классический firewall (iptables/nftables) работает с IP и портами, а не с доменом. Блокировать “по имени” трудно, потому что один IP обслуживает сотни доменов (CDN), а IP меняются. Некоторые решения анализируют TLS SNI, чтобы понять домен, но это ограничено и со временем может ухудшаться из-за внедрения ECH (Encrypted Client Hello).
Поэтому надёжный контроль по домену — это DNS-фильтрация + анти-обход (DoH/DoT), либо полноценный прокси/UTM, который умеет политики, идентификацию и отчёты. В корпоративной среде UTM (в том числе Fortinet) часто выбирают именно из-за комбинации фильтрации и журналирования.
4) Прокси: максимум контроля и логирование
HTTP/HTTPS прокси (например Squid) позволяет ограничивать доступ по домену, URL-шаблонам, категориям, пользователям и расписаниям. Он также даёт логи для анализа. В HTTPS есть два режима: (1) фильтрация на уровне CONNECT — видно домен, но не видно полный URL; (2) TLS инспекция — видно URL/контент, но нужно развернуть доверенный CA сертификат и иметь понятную политику/юридическое основание. Во многих сценариях для “блокировать домены” достаточно режима (1).
Прокси бывает “явным” (клиенты настраивают прокси) и “прозрачным” (трафик перенаправляется). Прозрачный прокси в мире современного HTTPS сложнее и может ломать некоторые приложения, поэтому чаще выбирают явный прокси + сетевую политику, чтобы обходить было сложнее. Размещают прокси обычно на VPS или внутреннем сервере.
Как выбрать метод под задачу
Если нужно заблокировать пару доменов на одном ПК — достаточно hosts. Если нужно блокировать для всей сети — выбирайте DNS-фильтрацию, это проще всего поддерживать. Если нужна строгая политика, пользователи, отчёты и логи — используйте прокси или UTM. На практике лучший результат часто даёт комбинация: DNS режет базовый список, а firewall/proxy усложняет обход и даёт прозрачность.
И всегда учитывайте обходы: VPN, DoH/DoT, мобильный интернет, альтернативный DNS и настройки браузеров. Если цель — реальный контроль в организации, нужна не только техника, но и процесс: кто может менять DNS, как управляются устройства, как оформляются исключения. Иначе “работает” только до первого пользователя, который умеет обходить ограничения.