iptables заблокировать веб-сайты https

9

Я хочу заблокировать в моей организации несколько веб-сайтов, которые также работают по протоколу 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 по-прежнему работает на машинах, кроме локальной машины.

iptables filter

— Dharmit
источник

2

Вы должны объяснить своей компании, что избегать использования https для личной учетной записи - не очень хорошая идея, поскольку это может привести к краже личных данных внутри компании, развертывание сертификата на всех компьютерах и действия в качестве человека в середине - гораздо лучший способ проверить, кто подключение к фейсбуку. Также я не уверен, но я думаю, что больше невозможно подключить Gmail без https.

— Kiwy

— Могу ли

12

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

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

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

— pr0f3550r
источник

может ли это блокировать все, что соответствует www.facebook.com, даже в теле html, но это допустимо, как это в поле для комментариев. Он может быть заблокирован на уровне URL, но как насчет IPaddress?

— Nikhil Mulley

@NikhilMulley: Нет, он будет соответствовать только SSL-сертификату, предоставленному Facebook. Все остальное зашифровано и не может быть видно.

— Багамат

2

Только первый пакет соединения входит в natтаблицу (и в таблице nat нет цепочки INPUT), я думаю, что вы имели в виду filter. Кроме того, существует (очень) отдаленная вероятность того, что он сопоставляет пакеты, где 443 является клиентским портом

— Стефан Шазелас

Кто-нибудь использовал это решение? Помимо отсутствия -p tcpправила, это не кажется чем-то полезным ..

— ivanleoncz

10

Брандмауэр не может контролировать, какие 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-адреса, которые позволят вам сообщить, что вы выполнили свою работу, независимо от того, насколько бесполезны).

— Жиль "ТАК - перестань быть злым"
источник

1

Профессиональный брандмауэр, такой как Checkpoint, позволяет фильтровать https без развертывания сертификата клиента в последней версии, я не знаю, как им это удается, но это работает.

— Киви

4

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

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

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

— Никхил Мулли
источник

+1 за это. Это можно сделать, вставив эти ссылки в /etc/hostsфайл. Например:127.0.0.1 www.facebook.com

2

Или, для более цивилизованного решения, задайте записи DNS A (или записи hosts / hosts.txt) для ссылки на хост интрасети с веб-сервером, который точно объясняет, почему пользователь не был отправлен в Facebook и т. Д. Обратите внимание, что это прерывает HTTPS, потому что предполагаемое имя хоста (например, www.facebook.com) не будет соответствовать сертификату CN.

— Алексиос

@Alexios: OpenDNS - отличное решение для этого.

— Кевин М,

@KevinM: спасибо, это полезно знать. Я буду иметь это в виду (хотя у нас есть собственная небольшая ферма DNS на работе)

— Alexios

2

Опция заключается в черном дыре маршрутов к сетевым блокам: (перечислены для 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

— сам
источник

1

Нет, это не так просто, сложно вести список ip для фейсбука, твиттера или даже гугла, которые больше не передают свои собственные диапазоны ip.

— Kiwy

1

Фильтр простого контента не может заблокировать сайт 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.

— Четан Мунешвар
источник

0

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

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

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

— Senthamil
источник