Доступ в интернет только избранным (pfSense + Active Directory)
-
Дано: домен 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 :-[
-
для контроллера домена откройте udp-53, а tcp-80(443) не открывайте и будет работать
шлюзом по умолчанию у вас pfsense или dc?
-
для контроллера домена откройте udp-53, а tcp-80(443) не открывайте и будет работать
Сделал по вашему совету, интернет появился на ВСЕХ рабочих станциях, а не только на тех, что в группе internet_YES
Под выражением "интернет появился" я подразумеваю открытие сайтов в браузере. Если убрать 2е сверху правило - сайты открываться не будут у ВСЕХ.
шлюзом по умолчанию у вас pfsense или dc?
Шлюз по-умолчанию pfSense, он же DHCP-сервер
-
Создайте правила отдельно для TCP и отдельно для UDP. TCP/UDP бывают глюки
-
Создайте правила отдельно для TCP и отдельно для UDP. TCP/UDP бывают глюки
Сделал. То же самое - интернет появился на ВСЕХ рабочих станциях (а не только на тех, что в группе internet_YES). Если убрать 2е сверху правило - сайты не будут открываться у ВСЕХ.
-
После изменений делаете filter reload?
-
После изменений делаете filter reload?
Да. Заодно во время тестов использую режим инкогнито в гугл хроме чтобы никакие кеши не помешали. Чтобы перестраховаться - при малейших подозрениях о том, что где-то что-то закешировалось - перезагружаю тестовые клиентские машины.
-
Я вот вообще думаю - а реально ли эту задачу сделать при помощи файрволла?
Как бы с его помощью это логически верно - рубить трафик еще до обработки всякими squid'ами.
Но ведь в моем случае DNS-запрос к pfSense исходит не от рабочей станции, а от контроллера домена. А pfSense, в свою очередь, не знает - какая рабочая станция прислала контроллеру домена запрос - из группы internet_YES или еще из какой-то ::)
-
Блин пытаюсь настроить прозрачный прокс с фильтрацией и доступ в интернет только определенной группе.не пока как рыба от лед. ожт кто то так настроил траспаред с юзер аутентификацией не работает да? кто знает?м
-
@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.
-
@dimonprodigy:
Я вот вообще думаю - а реально ли эту задачу сделать при помощи файрволла?
…Вполне. Если Вы не пользователей, а компьютеры с фиксированными IP адресами ограничиваете.
@dimonprodigy:
…
Но ведь в моем случае DNS-запрос к pfSense исходит не от рабочей станции, а от контроллера домена. А pfSense, в свою очередь, не знает - какая рабочая станция прислала контроллеру домена запрос - из группы internet_YES или еще из какой-то ::)Для Вас это плохо, если "ограниченные" компьютеры получают адреса внешних сайтов? Если да, можно что-нибудь придумать…
Хотя классическое и более безопасное решение - proxy.
-
-
Для Вас это плохо, если "ограниченные" компьютеры получают адреса внешних сайтов? Если да, можно что-нибудь придумать…
Хотя классическое и более безопасное решение - 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 пф. И тогда появится возможность рубить доступ к сайтам на уровне ДНС. Если исп-ся ДНС Резолвер на пф, конечно.
-
Добрый.
Заверните все ДНС-запросы вовне на ЛАН 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 в вялотекущем режиме, параллельно с другими задачами. ???
