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

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

Таким образом, решение состоит в том, чтобы загрузить загрузочный CD изображение ISO как SystemRescueCD или живой Gparted. Добавьте его к своей виртуальной машине (только в меню, которое Вы показали в своем изображении - выбирают "Контроллер SATA", нажимают значок "Add CD/DVD Device" и затем, справа, обзор для Вашего файла ISO), и установите для начальной загрузки от этого вместо образа диска (но не удаляйте изображение, конечно). После того как Вы загрузились, выполнение gparted и измените размер раздела. Завершите работу машины, удалите ISO из нее и загрузитесь назад к Вашему виртуальному диску :)

9
27.01.2012, 22:44
6 ответов

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

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

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

11
27.01.2020, 20:04
  • 1
    может этот блок что-либо, что соответствует www.facebook.com даже в теле HTML, но это законно как это на поле комментария. Это может быть заблокировано на уровне URL, но что относительно ipaddress? –  Nikhil Mulley 28.01.2012, 13:06
  • 2
    @NikhilMulley: Нет, это будет только соответствовать сертификату SSL, врученному Facebook. Все остальное шифруется и не может быть замечено. –  bahamat 24.07.2012, 01:33
  • 3
    Только первый пакет соединения входит nat таблица (и нет никакой ВХОДНОЙ цепочки в туземной таблице), я думаю, что Вы имели в виду filter там. Кроме того, существует (очень) удаленный шанс, что это соответствует пакетам, где 443 клиентский порт –  Stéphane Chazelas 31.10.2012, 00:03
  • 4
    кто-либо использовал это решение? Независимо недостатка -p tcp для правила это, кажется, не что-то полезное.. –  ivanleoncz 27.09.2017, 21:53

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

Единственный реалистический способ заблокировать HTTPS состоит в том, чтобы заблокировать его в целом. Настаивайте, чтобы всеми соединениями был допустимый HTTP (т.е. клиент запускает путем отправки HTTP строка, и так далее). Это не может быть, покончили просто IPtables, Вам нужен осведомленный о действующем протоколе прокси, такой как Сквид. (Я не знаю то, к чему Облегченная Untangle способна.)

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

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

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

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

10
27.01.2020, 20:04
  • 1
    как Контрольная точка позволяет https, фильтрующий, не развертывая клиентский сертификат в последней версии, я не знаю, как им удается сделать это, но это работает. –  Kiwy 11.03.2014, 11:01

Я знаю об одной опции.

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

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

4
27.01.2020, 20:04
  • 1
    +1 для этого. Это может быть сделано путем вставки этих ссылок в /etc/hosts файл. Например: 127.0.0.1 www.facebook.com –   11.01.2012, 16:45
  • 2
    Или, для более цивилизованного решения, устанавливает DNS записи (или записи hosts/hosts.txt) для обращения к хосту интранет с веб-сервером, который объясняет точно, почему пользователь не был отправлен в Facebook, и т.д. Обратите внимание на то, что это повреждает HTTPS, потому что намеченное имя хоста (например, www.facebook.com) не будет соответствовать сертификату CN. –  Alexios 12.01.2012, 09:26
  • 3
    @Alexios: OpenDNS является отличным решением для этого. –  Kevin M 28.01.2012, 15:27
  • 4
    @KevinM: спасибо, это полезно для знания. Я буду иметь в виду его (хотя у нас есть наша собственная небольшая ферма DNS на работе) –  Alexios 28.01.2012, 15:47

Опция состоит в том, чтобы поместить маршруты в черный список к сетевым блокам: (Перечисленный для 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
2
27.01.2020, 20:04
  • 1
    не, который это не, это путь к сложному для ведения списка IP для Facebook, пишет в Твиттере или даже Google, кто больше не передает свои собственные диапазоны диапазона IP. –  Kiwy 11.03.2014, 11:05

Необходимо поставить, это ПЕРЕДАЕТ цепочку, например.

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

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

0
27.01.2020, 20:04

Простой фильтр контента не может заблокировать ssl сайт.

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

Демонстрационное правило IPS: Для блокирования ssl URL для определенного 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 правилах политики, совместно использованных Сквидом + Suricata IPS.

1
27.01.2020, 20:04

Теги

Похожие вопросы