Доступ в интернет только избранным (pfSense + Active Directory)
-
Для Вас это плохо, если "ограниченные" компьютеры получают адреса внешних сайтов? Если да, можно что-нибудь придумать…
Хотя классическое и более безопасное решение - proxy.
Что вы имеете ввиду под выражением "получают адреса"? Могут пингануть внешний сайт?
-
Хотя классическое и более безопасное решение - 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.- 3 и 4 снизу правила убрал, они действительно лишние.
- Так выглядят пинги и попытки пингов на любой ресурс, в данном случае мой тестовый сайт. Сразу понятно - кто лез и почему получилось или не получилось пингануть:
- А так выглядит открытие сайтов в браузере с любого компа в сети (DNS-сервер = контроллер домена 10.0.0.1).
Видимо, файрволом не решить такую задачу - за открытие сайтов по доменному имени отвечает DNS, а DNS - это контроллер домена. pfSense либо пропускает от него запросы либо нет
-
Добрый.
Заверните все ДНС-запросы вовне на ЛАН 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) -
Добрый.
Заверните все ДНС-запросы вовне на ЛАН ip пф. И тогда появится возможность рубить доступ к сайтам на уровне ДНС. Если исп-ся ДНС Резолвер на пф, конечно.Да, DNS resolver используется pfSense.
Дык DNS запросы и так заворачиваются:
на pfSense (10.0.0.3) приходят в таком виде (10.0.0.1 - контроллер домена+DNS сервер для рабочих станций, в настройках которого прописан forwarder, скриншот выше):
-
@dimonprodigy:
Что вы имеете ввиду под выражением "получают адреса"? Могут пингануть внешний сайт?
получают ответ с адресом на DNS запрос по UDP 53. В случае ping, Вы видите IP адрес внешнего сайта. Самому ping-у проходить необязательно (зависит от конфигурации), ведь у Вас цель - TCP 443, 80, а не ICMP.
-
@dimonprodigy:
Попробуйте включить 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-сервер уже в "открытии сайтов по доменному имени" не участвует.
-
@dimonprodigy:
Хотя классическое и более безопасное решение - proxy.
То есть, не файрволом предлагаете рубить на дальних рубежах, а сквидом не пущать на сайты?
Файрволом рубить всё всем, кроме squid-сервера. Ну, а в squit-е настроить, кому куда можно.
-
Сейчас Ваша проблема, это TCP на порты 80, 443.
Хоть убейте не пойму - почему вы называете это проблемой? Как раз таки ЭТО - имхо не проблема. Хочу разрешаю, а хочу запрещаю. Все наглядно и прозрачно
В то время как UDP-DNS трафик идет с контроллера домена на pfSense общей кучей и непонятно кто первоисточник. То есть, кого посылать, а кого пропускать :D
-
@dimonprodigy:
Сейчас Ваша проблема, это TCP на порты 80, 443.
Хоть убейте не пойму - почему вы называете это проблемой? Как раз таки ЭТО - имхо не проблема. Хочу разрешаю, а хочу запрещаю. Все наглядно и прозрачно
…То есть, Вы уже разобрались с тем, что не смотря на то, что не все компьютеры в internet_YES, все они могут открывать внешние сайты, если удастся заполучить их IP адреса?
@dimonprodigy:
…
В то время как UDP-DNS трафик идет с контроллера домена на pfSense общей кучей и непонятно кто первоисточник. То есть, кого посылать, а кого пропускать :DЗаверните все ДНС-запросы вовне на ЛАН ip пф. И тогда появится возможность рубить доступ к сайтам на уровне ДНС. Если исп-ся ДНС Резолвер на пф, конечно.
Хотя я подумал, и сходу пока не придумал, как организовать фильтрацию. Ну, придёт DNS запрос к pfSense. Ну, поймёт pfSense, что запрос вовне должен идти. А дальше-то что? Для разрешения имени этот самый "ДНС Резолвер" с адреса pfSense пошлёт вовне новый DNS запрос, который нам иногда хочется блокировать. Но адреса изначального инициатора на этом этапе уже нет…
@werter, что я упускаю?
-
То есть, Вы уже разобрались с тем, что не смотря на то, что не все компьютеры в internet_YES, все они могут открывать внешние сайты, если удастся заполучить их IP адреса?
Нет, не разобрался :(
Но так происходит как только я разрешаю на pfSens'e (10.0.0.3) обрабатывать DNS-UDP запросы от контроллера домена (10.0.0.1). Который, в свою очередь, является единственным DNS-сервером для каждой рабочей станции. Поэтому я и грешу на какую-то нестыковку DNS. Типа, если бы за DNS отвечал BIND в pfSense - такой ситуации бы не было. -
@dimonprodigy:
Сейчас Ваша проблема, это TCP на порты 80, 443.
Хоть убейте не пойму - почему вы называете это проблемой? Как раз таки ЭТО - имхо не проблема. Хочу разрешаю, а хочу запрещаю. Все наглядно и прозрачно
В то время как UDP-DNS трафик идет с контроллера домена на pfSense общей кучей и непонятно кто первоисточник. То есть, кого посылать, а кого пропускать :D
@dimonprodigy:
То есть, Вы уже разобрались с тем, что не смотря на то, что не все компьютеры в internet_YES, все они могут открывать внешние сайты, если удастся заполучить их IP адреса?
Нет, не разобрался :(
…И что же для Вас тогда главная проблема? То что DNS работает не совсем так, как хочется, причём понятно почему, или то, что по IP адресам любой из Вашей сети получает доступ вовне по портам 80 и 443, хотя Вы пытаетесь это блокировать?
Для меня главной была бы вторая проблема. Но допускаю и наличие других точек зрения.
@dimonprodigy:
…
Типа, если бы за DNS отвечал BIND в pfSense - такой ситуации бы не было.А в этом я уже не уверен:
…
Хотя я подумал, и сходу пока не придумал, как организовать фильтрацию. Ну, придёт DNS запрос к pfSense. Ну, поймёт pfSense, что запрос вовне должен идти. А дальше-то что? Для разрешения имени этот самый "ДНС Резолвер" с адреса pfSense пошлёт вовне новый DNS запрос, который нам иногда хочется блокировать. Но адреса изначального инициатора на этом этапе уже нет...@werter, что я упускаю?
-
И что же для Вас тогда главная проблема? То что DNS работает не совсем так, как хочется, причём понятно почему, или то, что по IP адресам любой из Вашей сети получает доступ вовне по портам 80 и 443, хотя Вы пытаетесь это блокировать?
Для меня главной была бы вторая проблема.
Да, вы правы - вторая проблема главнее. Действительно, если узнать ип-адрес какого-нить сайта, то в браузере на рабочей станции можно открыть оный сайт (невзирая на то, что данной рабочей станции запрещен доступ в интернет) ;D А самое "прикольное" - допустим, открыл я в браузере на тестовой рабочей станции 10.0.0.12 свой сайт по ip-адресу 5.101.116.208. Лезу в логи, в них только такое. Уж спрошу на всякий случай - так и должно быть?
-
@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.
-
по правилам хорошего тона, отписываюсь о решенной проблеме. Сам не дотумкал и дернул знакомого хорошего линуксоида, который разобрался. Причина была, по его словам, в Squid.
То есть, решение задачи найдено и выглядит так:Squid + Squidguard при этом не активны. Их включение, настройка и т.д. - отдельная тема. Данная же задача в ее изначальной формулировке решена.
-
Поздравляю!
Однако,
@dimonprodigy:
Причина была, по его словам, в Squid.
Так у Вас там ещё и squid работал!?
О таких вещах писать надо, батенька! Ну и, разумеется, прямые вопросы не игнорировать:
Вопрос, конечно, странный, но может где-то proxy спрятался?
-
Добрый.
Если сквид - прозрачный, то выпускать "избранных" мимо него можно просто добавив их ip в настройках сквида в source.
Создавать явные правила fw для этого не требуется.Сам не дотумкал и дернул знакомого хорошего линуксоида, который разобрался. Причина была, по его словам, в Squid.
Сквид ни при чем.
-
Поздравляю!
Однако,
@dimonprodigy:
Причина была, по его словам, в Squid.
Так у Вас там ещё и squid работал!?
О таких вещах писать надо, батенька! Ну и, разумеется, прямые вопросы не игнорировать:
Вопрос, конечно, странный, но может где-то proxy спрятался?
Да, виноват, проштрафился. :D При словах "может где-то proxy" я несколько раз думал о прокси внешнем, а не внутреннем. Хз почему ;D
-
Добрый.
Если сквид - прозрачный, то выпускать "избранных" мимо него можно просто добавив их ip в настройках сквида в source.
Создавать явные правила fw для этого не требуется.Задача была в том, чтобы, имея pfSense в кач-ве "шлюза по-умолчанию", по-умолчанию запрещать устройствам выход в интернет. Как явный - доступ к сайтам. Так и неявный - проверку обновлений, лазание в фоне по каким-то экзотическим портам и т.д.
Грубо говоря:
- подключил комп
- dhcp-сервер выдал компу ip…
3)... и все - пока явно не разрешишь - pfSense должен блокировать любые поползновения в интернет.
Мне показалось логичным блокировать при помощи firewall. Задача следующая - кастомизировать доступ к разным сайтам, кому куда можно.
Хотя я могу ошибаться насчет логичности - я только неделю как ковыряю pfSense в вялотекущем режиме, параллельно с другими задачами. ???