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

Jetberry

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

Guest

Создайте правила отдельно для 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-е настроить, кому куда можно.

Guest

@yarick123:

Сейчас Ваша проблема, это TCP на порты 80, 443.

Хоть убейте не пойму - почему вы называете это проблемой? Как раз таки ЭТО - имхо не проблема. Хочу разрешаю, а хочу запрещаю. Все наглядно и прозрачно

В то время как UDP-DNS трафик идет с контроллера домена на pfSense общей кучей и непонятно кто первоисточник. То есть, кого посылать, а кого пропускать :D

yarick123

@dimonprodigy:

@yarick123:

Сейчас Ваша проблема, это TCP на порты 80, 443.

Хоть убейте не пойму - почему вы называете это проблемой? Как раз таки ЭТО - имхо не проблема. Хочу разрешаю, а хочу запрещаю. Все наглядно и прозрачно
…

То есть, Вы уже разобрались с тем, что не смотря на то, что не все компьютеры в internet_YES, все они могут открывать внешние сайты, если удастся заполучить их IP адреса?

@dimonprodigy:

…
В то время как UDP-DNS трафик идет с контроллера домена на pfSense общей кучей и непонятно кто первоисточник. То есть, кого посылать, а кого пропускать :D

@werter предложил:
@werter:

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

Хотя я подумал, и сходу пока не придумал, как организовать фильтрацию. Ну, придёт DNS запрос к pfSense. Ну, поймёт pfSense, что запрос вовне должен идти. А дальше-то что? Для разрешения имени этот самый "ДНС Резолвер" с адреса pfSense пошлёт вовне новый DNS запрос, который нам иногда хочется блокировать. Но адреса изначального инициатора на этом этапе уже нет…

@werter, что я упускаю?

Guest

@yarick123:

То есть, Вы уже разобрались с тем, что не смотря на то, что не все компьютеры в internet_YES, все они могут открывать внешние сайты, если удастся заполучить их IP адреса?

Нет, не разобрался :(
Но так происходит как только я разрешаю на pfSens'e (10.0.0.3) обрабатывать DNS-UDP запросы от контроллера домена (10.0.0.1). Который, в свою очередь, является единственным DNS-сервером для каждой рабочей станции. Поэтому я и грешу на какую-то нестыковку DNS. Типа, если бы за DNS отвечал BIND в pfSense - такой ситуации бы не было.