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

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 - такой ситуации бы не было.

yarick123

@dimonprodigy:

@yarick123:

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

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

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

@dimonprodigy:

@yarick123:

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

Нет, не разобрался :(
…

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

Для меня главной была бы вторая проблема. Но допускаю и наличие других точек зрения.

@dimonprodigy:

…
Типа, если бы за DNS отвечал BIND в pfSense - такой ситуации бы не было.

А в этом я уже не уверен:

@yarick123:

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

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

Guest

@yarick123:

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

Для меня главной была бы вторая проблема.

Да, вы правы - вторая проблема главнее. Действительно, если узнать ип-адрес какого-нить сайта, то в браузере на рабочей станции можно открыть оный сайт (невзирая на то, что данной рабочей станции запрещен доступ в интернет) ;D А самое "прикольное" - допустим, открыл я в браузере на тестовой рабочей станции 10.0.0.12 свой сайт по ip-адресу 5.101.116.208. Лезу в логи, в них только такое. Уж спрошу на всякий случай - так и должно быть?

yarick123

@dimonprodigy:

допустим, открыл я в браузере на тестовой рабочей станции 10.0.0.12 свой сайт по ip-адресу 5.101.116.208. Лезу в логи, в них только такое. Уж спрошу на всякий случай - так и должно быть?

В принципе, всё нормально. Зависит от того, какие сервисы на Вашем компьютере настроены.

https://www.speedguide.net/port.php?port=137
https://www.speedguide.net/port.php?port=5355

Ищете, как таки проходят tcp пакеты на порты 80, 443.

Guest

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

Squid + Squidguard при этом не активны. Их включение, настройка и т.д. - отдельная тема. Данная же задача в ее изначальной формулировке решена.

yarick123

Поздравляю!

Однако,

@dimonprodigy:

Причина была, по его словам, в Squid.

Так у Вас там ещё и squid работал!?

О таких вещах писать надо, батенька! Ну и, разумеется, прямые вопросы не игнорировать:

@yarick123:

Вопрос, конечно, странный, но может где-то proxy спрятался?

werter

Добрый.
Если сквид - прозрачный, то выпускать "избранных" мимо него можно просто добавив их ip в настройках сквида в source.
Создавать явные правила fw для этого не требуется.

Сам не дотумкал и дернул знакомого хорошего линуксоида, который разобрался. Причина была, по его словам, в Squid.

Сквид ни при чем.