Доступ в интернет только избранным (pfSense + Active Directory)

Guest

Дано: домен active directory + pfSense.
Задача: сделать чтобы по-умолчанию pfSense не пускал в интернет рабочие станции и доступ в интернет был только для явно разрешенных рабочих станций.

Казалось бы - все просто. В pfSense:
1. Firewall >> rules >> LAN >> поменять 2 дефолтных правила с Pass на Block
2. Firewall >> aliases >> IP >> создать группу, куда включить ip рабочих станций, которым нужен интернет
3. Firewall >> rules >> LAN >> создать 3 разрешающих правила (для 53, 80, 443 портов) для группы из п.2
4. Перезагрузить firewall

Заковыка в том, что за DNS отвечает сервер Active Directory. Выглядит это так:

То есть, контроллер домена все запросы к ресурсам, которые не может обработать сам - пересылает на шлюз (в данном случае pfSense). Для домена Active Directory это обычная конфигурация.

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

Посоветуйте как решить задачу? Че-то я явно делаю не так по части DNS :-[

Jetberry

для контроллера домена откройте udp-53, а tcp-80(443) не открывайте и будет работать
шлюзом по умолчанию у вас pfsense или dc?

Guest

@Jetberry:

для контроллера домена откройте udp-53, а tcp-80(443) не открывайте и будет работать

Сделал по вашему совету, интернет появился на ВСЕХ рабочих станциях, а не только на тех, что в группе internet_YES

Под выражением "интернет появился" я подразумеваю открытие сайтов в браузере. Если убрать 2е сверху правило - сайты открываться не будут у ВСЕХ.

@Jetberry:

шлюзом по умолчанию у вас pfsense или dc?

Шлюз по-умолчанию pfSense, он же DHCP-сервер

Jetberry

Создайте правила отдельно для TCP и отдельно для UDP. TCP/UDP бывают глюки

Guest

@Jetberry:

Создайте правила отдельно для TCP и отдельно для UDP. TCP/UDP бывают глюки

Сделал. То же самое - интернет появился на ВСЕХ рабочих станциях (а не только на тех, что в группе internet_YES). Если убрать 2е сверху правило - сайты не будут открываться у ВСЕХ.

Jetberry

После изменений делаете filter reload?

Guest

@Jetberry:

После изменений делаете filter reload?

Да. Заодно во время тестов использую режим инкогнито в гугл хроме чтобы никакие кеши не помешали. Чтобы перестраховаться - при малейших подозрениях о том, что где-то что-то закешировалось - перезагружаю тестовые клиентские машины.

Guest

Я вот вообще думаю - а реально ли эту задачу сделать при помощи файрволла?

Как бы с его помощью это логически верно - рубить трафик еще до обработки всякими squid'ами.

Но ведь в моем случае DNS-запрос к pfSense исходит не от рабочей станции, а от контроллера домена. А pfSense, в свою очередь, не знает - какая рабочая станция прислала контроллеру домена запрос - из группы internet_YES или еще из какой-то ::)

nickadmov

Блин пытаюсь настроить прозрачный прокс с фильтрацией и доступ в интернет только определенной группе.не пока как рыба от лед. ожт кто то так настроил траспаред с юзер аутентификацией не работает да? кто знает?м

yarick123

@dimonprodigy:

Сделал. То же самое - интернет появился на ВСЕХ рабочих станциях (а не только на тех, что в группе internet_YES). Если убрать 2е сверху правило - сайты не будут открываться у ВСЕХ.

А как у Вас выглядит internet_YES?

Такое ощущение, что в Итнернет у Вас и так все ходить могут, но "Если убрать 2е сверху правило", никто не может получить IP-адреса внешних сайтов. Вопрос, конечно, странный, но может где-то proxy спрятался?

Попробуйте включить logging для разрешающих правил TCP на порты 80, 443 и посмотреть, кто же до Интернета по ним доходит.

Да и с DNS у Вас как-то всё путано. 10.0.0.3 это pfSense? Он тоже в Вашей конфигурации DNS resolving осуществлять должен? testgw.testdomain.com в таблице DNS отсутствует… Работать, конечно, будет, но как-то вся конфигурация вцелом странно выглядит.

P.S. Для чистоты эксперимента, я бы 3-е и 4-е снизу правила убрал, коль для 10.0.0.1 всё явно прописано во 2-ом сверху правиле.
P.P.S. Не вижу необходимости разрешать UDP на порты 443, 80.

yarick123

@dimonprodigy:

Я вот вообще думаю - а реально ли эту задачу сделать при помощи файрволла?
…

Вполне. Если Вы не пользователей, а компьютеры с фиксированными IP адресами ограничиваете.

@dimonprodigy:

…
Но ведь в моем случае DNS-запрос к pfSense исходит не от рабочей станции, а от контроллера домена. А pfSense, в свою очередь, не знает - какая рабочая станция прислала контроллеру домена запрос - из группы internet_YES или еще из какой-то ::)

Для Вас это плохо, если "ограниченные" компьютеры получают адреса внешних сайтов? Если да, можно что-нибудь придумать…

Хотя классическое и более безопасное решение - proxy.

Guest

@yarick123:

А как у Вас выглядит internet_YES?

В нем 2 ip рабочих станций

Guest

@yarick123:

Для Вас это плохо, если "ограниченные" компьютеры получают адреса внешних сайтов? Если да, можно что-нибудь придумать…

Хотя классическое и более безопасное решение - proxy.

Что вы имеете ввиду под выражением "получают адреса"? Могут пингануть внешний сайт?

Guest

@yarick123:

Хотя классическое и более безопасное решение - proxy.

То есть, не файрволом предлагаете рубить на дальних рубежах, а сквидом не пущать на сайты?

Guest

@yarick123:

Попробуйте включить logging для разрешающих правил TCP на порты 80, 443 и посмотреть, кто же до Интернета по ним доходит.

Да и с DNS у Вас как-то всё путано. 10.0.0.3 это pfSense? Он тоже в Вашей конфигурации DNS resolving осуществлять должен? testgw.testdomain.com в таблице DNS отсутствует… Работать, конечно, будет, но как-то вся конфигурация вцелом странно выглядит.

P.S. Для чистоты эксперимента, я бы 3-е и 4-е снизу правила убрал, коль для 10.0.0.1 всё явно прописано во 2-ом сверху правиле.
P.P.S. Не вижу необходимости разрешать UDP на порты 443, 80.

3 и 4 снизу правила убрал, они действительно лишние.
Так выглядят пинги и попытки пингов на любой ресурс, в данном случае мой тестовый сайт. Сразу понятно - кто лез и почему получилось или не получилось пингануть:

А так выглядит открытие сайтов в браузере с любого компа в сети (DNS-сервер = контроллер домена 10.0.0.1).

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

werter

Добрый.
Заверните все ДНС-запросы вовне на ЛАН ip пф. И тогда появится возможность рубить доступ к сайтам на уровне ДНС. Если исп-ся ДНС Резолвер на пф, конечно.

![Firewall_ NAT_ Port Forward.png](/public/imported_attachments/1/Firewall_ NAT_ Port Forward.png)
![Firewall_ NAT_ Port Forward.png_thumb](/public/imported_attachments/1/Firewall_ NAT_ Port Forward.png_thumb)
![Firewall_ Rules_ LAN.png](/public/imported_attachments/1/Firewall_ Rules_ LAN.png)
![Firewall_ Rules_ LAN.png_thumb](/public/imported_attachments/1/Firewall_ Rules_ LAN.png_thumb)
![Services_ DNS Resolver_ General Settings.png](/public/imported_attachments/1/Services_ DNS Resolver_ General Settings.png)
![Services_ DNS Resolver_ General Settings.png_thumb](/public/imported_attachments/1/Services_ DNS Resolver_ General Settings.png_thumb)

Guest

@werter:

Добрый.
Заверните все ДНС-запросы вовне на ЛАН ip пф. И тогда появится возможность рубить доступ к сайтам на уровне ДНС. Если исп-ся ДНС Резолвер на пф, конечно.

Да, DNS resolver используется pfSense.

Дык DNS запросы и так заворачиваются:

на pfSense (10.0.0.3) приходят в таком виде (10.0.0.1 - контроллер домена+DNS сервер для рабочих станций, в настройках которого прописан forwarder, скриншот выше):

yarick123

@dimonprodigy:

Что вы имеете ввиду под выражением "получают адреса"? Могут пингануть внешний сайт?

получают ответ с адресом на DNS запрос по UDP 53. В случае ping, Вы видите IP адрес внешнего сайта. Самому ping-у проходить необязательно (зависит от конфигурации), ведь у Вас цель - TCP 443, 80, а не ICMP.

yarick123

@dimonprodigy:

@yarick123:

Попробуйте включить logging для разрешающих правил TCP на порты 80, 443 и посмотреть, кто же до Интернета по ним доходит.
…

…
2) Так выглядят пинги и попытки пингов на любой ресурс, в данном случае мой тестовый сайт. Сразу понятно - кто лез и почему получилось или не получилось пингануть:

...

А так выглядит открытие сайтов в браузере с любого компа в сети (DNS-сервер = контроллер домена 10.0.0.1).

...

В данном случае, интересны данные именно о TCP на порты 80, 443, а не ping (ICMP) и DNS (UDP 53).

@dimonprodigy:

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

"Вам шашечки или ехать?" С DNS можно разобраться позже, если Вам это действительно надо (@werter уже написал, как). Сейчас Ваша проблема, это TCP на порты 80, 443.

P.S. Не смог пройти мимо:
@dimonprodigy:

за открытие сайтов по доменному имени отвечает DNS

Нет. DNS отвечает за преобразование доменного имени в IP адрес. Пропишите на рабочем компьютере в hosts-файле правильные IP адреса сайтов, и DNS-сервер уже в "открытии сайтов по доменному имени" не участвует.

yarick123

@dimonprodigy:

@yarick123:

Хотя классическое и более безопасное решение - proxy.

То есть, не файрволом предлагаете рубить на дальних рубежах, а сквидом не пущать на сайты?

Файрволом рубить всё всем, кроме squid-сервера. Ну, а в squit-е настроить, кому куда можно.