iptables для блокировки https-сайтов

Я хочу заблокировать несколько сайтов, которые также работают на https, например facebook, twitter и gmail, в моей организации. Squid не предполагается использовать здесь в соответствии с заказами высшего руководства. Мы можем использовать пакет Untangle Lite и iptables .

Есть ли какой-либо вариант, кроме Squid, для этого? Также очень полезно использовать правило iptables для блокировки такого трафика.

я нашел это

 iptables -t filter -I INPUT -m string --string facebook.com -j LOG --algo bm iptables -t filter -I INPUT -m string --string facebook.com -j REJECT --algo bm 

но https все еще работает на машинах, кроме локальной машины.

  • учетная информация ipset
  • Fedora 25: настройки firewalld не вступят в силу
  • Блокировка исходящих соединений с iptables
  • Captive Portal на малине Pi (raspbian) с мостиковым адаптером
  • Блокировка веб-сайтов по дням и часам с использованием Iptables в OpenWRT
  • netfilter / iptables: почему бы не использовать исходную таблицу?
  • Сделать запрос через интерфейс vpn
  • Гости libvirt: принимают подключения извне сети
  • 6 Solutions collect form web for “iptables для блокировки https-сайтов”

    Вместо сопоставления на основе URL-адреса попробуйте выполнить сопоставление на основе содержимого сертификата.

     iptables -t nat -I INPUT --sport 443 -m string \ --string www.facebook.com --algo bm -j REJECT 

    Вы также можете соответствовать по отпечатку пальца, но если пункт назначения изменит или обновит свой сертификат, он аннулирует ваше правило.

    Брандмауэр не может контролировать URL-адрес HTTPS, к которому клиент пытается получить доступ, поскольку URL-адрес зашифрован. Брандмауэр может контролировать только те сайты, к которым клиент подключается, используя IP-адреса, но это не помогает, если версии HTTP и HTTPS сайта имеют один и тот же URL (и даже если это не так, для поддержания огромного списка IP-адресов).

    Единственный реалистичный способ блокировки HTTPS – полностью заблокировать его. Настаивайте на том, что все соединения должны быть действительными HTTP (т.е. клиент начинает с отправки HTTP строки и т. Д.). Это невозможно сделать только с помощью IPtables, вам нужен фактический прокси-сервер, поддерживающий протокол, такой как Squid. (Я не знаю, на что способен Untangle Lite).

    Вы можете заблокировать большинство HTTPS-трафика, заблокировав исходящий трафик на порт 443, поскольку почти все серверы HTTPS находятся на этом порту. Или, следуя принципу «белого списка», разрешите только исходящий трафик на порт 80 (обычный HTTP-порт).

    Другой подход – проксировать все HTTP и HTTPS-соединения. Затем вы можете сопоставлять URL-адреса. Для этого требуется проведение атаки «человек-в-середине» на клиентов. Это можно сделать, если вы разместите свой собственный центр сертификации на всех клиентских компьютерах и зарегистрируйте его там как корневой центр доверия. Это можно считать неэтичным.

    Независимо от того, что вы делаете, определенные пользователи будут устанавливать прокси вне вашей среды и запускать IP через HTTP или что-то в этом роде.

    Кажется, вы пытаетесь решить социальную проблему техническими средствами, которые почти никогда не работают, или делать все возможное, чтобы реализовать глупые требования от управления (в этом случае я бы пошел с блокирующим портом 443, возможно, только для определенные IP-адреса, которые позволят вам сообщать, что вы выполнили свою работу, независимо от того, насколько бесполезны).

    Я знаю один вариант.

    Если у вас есть внутренние DNS-серверы для использования, поместите некоторые статические ссылки в данные зоны зоны TLD, которые разрешают домены (которые вы не хотите устанавливать внешние подключения) до 127.0.0.1. Таким образом, все хосты, использующие центральный DNS в вашей сети, будут разрешать (facebook.com/twitter.com per se) домены в loopback-адресе, что ни к чему не приведет.

    Это будет работать, если у вас есть общий авторитетный контроль над конфигурацией преобразователя клиентских машин вашей сети. Если на рабочих станциях / клиентах есть права изменять / редактировать либо / etc / hosts, либо /etc/resolv.conf, они могут обойти эту опцию.

    Опция – это маршруты черной дыры к сетевым блокам: (Перечислены для FB)

     ip route add blackhole 69.171.224.0/19 ip route add blackhole 74.119.76.0/22 ip route add blackhole 204.15.20.0/22 ip route add blackhole 66.220.144.0/20 ip route add blackhole 69.63.176.0/20 ip route add blackhole 173.252.64.0/18 

    Обычный фильтр содержимого не может блокировать сайт ssl.

    Используйте инструменты защиты от вторжений, такие как snort / suricata.

    Пример правила IPS : для блокировки URL-адресов ssl для определенного IP-адреса.

    drop ip any 443 -> 192.168.3.30 any (content:".facebook.com"; msg:"Simplewall Ssl block for User30 : Urls => .facebook.com " sid:26648513;rev:1;)

    drop ip any 443 -> 192.168.3.30 any (content:".fbcdn.net"; msg:"Simplewall Ssl block for User30 : Urls => .fbcdn.net " ;sid:11469443;rev:1;)

    drop ip any 443 -> 192.168.3.30 any (content:".youtube.com"; msg:"Simplewall Ssl block for User30 : Urls => .youtube.com " ;sid:13989722;rev:1;)

    Загрузить Simplewall : в правилах политики simplewall, которые используются Squid + Suricata IPS.

    Вы должны поместить это в цепочку FORWARD, например

     iptables -I FORWARD -m string --string "facebook.com" \ --algo bm --from 1 --to 600 -j REJECT 

    Это повлияет на другие системы в сети, за исключением брандмауэра.

    Linux и Unix - лучшая ОС в мире.