16 Июнь 2019, 07:31

Цитата дня:

Если вы не можете объяснить что-либо простыми словами, вы это не понимаете. Ричард Фейнман


pfSense и внедрение его в инфраструктуру

Автор Призрак, 07 Апрель 2019, 12:52

« предыдущая тема - следующая тема »

0 Пользователей и 1 Гость просматривают эту тему.

Вниз

Призрак

Создал тему в этом разделе, так как эта, я думаю, прекрасная вещь, основана на операционной системе FreeBSD.

В последнее время меня стали сильно, очень сильно беспокоить попытки взлома шлюзов. В журналах аудита то и дело проскакивают попытки перебора паролей от неизвестных подонков, явно желтопузых, ботов. Самая большая ошибка, которую совершают администраторы, это пустой пароль к учётной записи администратора (это возможно, если "выкрутить" политику). У меня же пароли все сложные, состоят из букв, цифр, символов. Но всё равно меня сильно беспокоит и то, что имеются, как я думаю, проблемы с брандмауэром. Мне ведь сказали, что из коробки он блокирует всё, что это необходимо. Почему же он на WAN интерфейсе допускает тогда подключение по RDP? Весьма любопытно и интересно. Брандмауэр включён, дополнительно он включён на Traffic Inspector, но это не даёт уверенности в полной защите, потому - что я никак не могу сформировать правильный набор правил. Мне нужно лишь, чтобы был доступ к удаленному рабочему столу, чтобы приходила почта, качались обновления, был доступ к сетевым шарам только из подсетей. Остальное всё чтобы блокировалось намертво, в том числе доступ по RDP с белого адреса. В связи с этим у меня и появились вопросы.

1. Нужно ли и можно ли установить этот инструмент вместо микротиков, по крайней мере, на время? Я слышал, что есть неплохой VPN сервис прямо напрямую с pfSense?

2. Можно ли в таком случае Traffic Inspector использовать на машине с одним сетевым интерфейсом? Дело в том, что мы пока не научились работать со Squid, поэтому он пока должен остаться, в будущем же планируется переход на Squid.

3. Каким образом лучше настроить брандмауэр на pfSense? мне подсказывали, как настроить его на Mikrotik, точно так же? Но в pfSense нету понятий Related и Established, а если пустить весь трафик на разрешение, потом на запрет, как то это не катит.

4. Если же вопрос с pfSense не будет положительным, хотелось бы знать, как закрутить болты в брандмауэре Windows и в Traffic Inspector.

Уваров А.С.

Самая большая ошибка, которую совершают администраторы, это пустой пароль к учётной записи администратора (это возможно, если "выкрутить" политику).
Пустой пароль делает удаленные подключения невозможными. Никакой "серьезной ошибки" тут нет.

Мне ведь сказали, что из коробки он блокирует всё, что это необходимо. Почему же он на WAN интерфейсе допускает тогда подключение по RDP? Весьма любопытно и интересно.
Наверное потому, что вы включили RDP (из коробки - выключено), и в чем здесь криминал? Современный RDP c SSL + NLA достаточно безопасен.


1. Нужно ли и можно ли установить этот инструмент вместо микротиков, по крайней мере, на время? Я слышал, что есть неплохой VPN сервис прямо напрямую с pfSense?
Оно, конечно, можно, но нужно ли? pfSense умеет ровно все тоже самое, что и другие продукты. Никаких откровений вы там не найдете. Зато можно найти новых проблем, исключительно со спецификой BSD, по которой вряд-ли кто вам здесь подскажет. Но следует учитывать, что Mikrotik - это полностью аппаратное решение, здесь же вам потребуется ПК, что снижает надежность (ПК нужно обслуживать), либо тратиться на безвентиляторные ПК с нужным функционалом, а это достаточно недешево.


Можно ли в таком случае Traffic Inspector использовать на машине с одним сетевым интерфейсом? Дело в том, что мы пока не научились работать со Squid, поэтому он пока должен остаться, в будущем же планируется переход на Squid.
Точно не помню, если только как прокси - то можно, но именно служба прокси там работала отвратительно (как сейчас - не знаю).

Каким образом лучше настроить брандмауэр на pfSense? мне подсказывали, как настроить его на Mikrotik, точно так же? Но в pfSense нету понятий Related и Established, а если пустить весь трафик на разрешение, потом на запрет, как то это не катит.
Это не "понятия", а состояния соединения и не быть их не может. Любой уважающий себя брандмауэр должен уметь с ними работать. А принцип настройки везде один, вне зависимости от применяемого решения.


Если же вопрос с pfSense не будет положительным, хотелось бы знать, как закрутить болты в брандмауэре Windows и в Traffic Inspector.
Перед тем, как крутить - нужно отчетливо себе представлять что вы крутите и зачем. Иначе окажется что вы пытаетесь стрелять из пушки по комарам.

Призрак

Пустой пароль делает удаленные подключения невозможными. Никакой "серьезной ошибки" тут нет.
В политике можно включить подключение и с пустым паролем. Вы наверное этого не знали.

Наверное потому, что вы включили RDP (из коробки - выключено), и в чем здесь криминал? Современный RDP c SSL + NLA достаточно безопасен.
Я включил RDP, но вы наверное забыли, что у нас организация бюджетная и сборная солянка - даже компьютеры с Windows XP попадаются, какое уж тут безопасное подключение? Кроме того, теперь новые серверные системы не купить, политика государства такая, переходим на российскую операционную систему, которой нет. Я никогда не признаю российскую операционную систему, потому - что она с ворованным ядром.

Оно, конечно, можно, но нужно ли? pfSense умеет ровно все тоже самое, что и другие продукты. Никаких откровений вы там не найдете. Зато можно найти новых проблем, исключительно со спецификой BSD, по которой вряд-ли кто вам здесь подскажет. Но следует учитывать, что Mikrotik - это полностью аппаратное решение, здесь же вам потребуется ПК, что снижает надежность (ПК нужно обслуживать), либо тратиться на безвентиляторные ПК с нужным функционалом, а это достаточно недешево.
Может быть, тогда вы дадите нам денег на микротики? Я уже повторял, что средств пока нет. А микротик хороший стоит столько же, сколько и комп, я имею в виду стоечный. Видимо, надо купить на свои деньги и поставить, чтобы речь пока об этом не заходила на форуме. С BSD мне приходилось сталкиваться, достаточно сложная и капризная система, у меня на ней одно время крутился сайт. Пришлось научиться работать. Одно только обновление портов чего стоит и сборка ядра, часами может длиться.

Точно не помню, если только как прокси - то можно, но именно служба прокси там работала отвратительно (как сейчас - не знаю).
Я не знаю, как там работала служба прокси, но работает до сих пор. И имеет нормальную авторизацию по MAC, чего не имеет раздутый Squid, именно поэтому мы на него и не переходим.

Это не "понятия", а состояния соединения и не быть их не может. Любой уважающий себя брандмауэр должен уметь с ними работать. А принцип настройки везде один, вне зависимости от применяемого решения.
Ну покажите мне, скиньте пару скринов, я и поверю. И на слово понятия не надо ругаться, вполне нормальное слово.

Перед тем, как крутить - нужно отчетливо себе представлять что вы крутите и зачем. Иначе окажется что вы пытаетесь стрелять из пушки по комарам.
Я кажется конкретно намекнул, что мне нужно. Запретить по белому адресу доступ к RDP, разрешить доступ только из конкретной подсети (10.0, 20.0, 30.0, 50.0, 60.0) через удаленный рабочий стол, а также всяким службам, вроде DNS. А у меня такое чувство, что стреляю я из пушки по комарам только пытаясь получить хоть какую - то наводку на этом форуме.

Вы можете конструктивно сказать, хоть раз, безо всяких издёвок и подколок? Написать правила? Я уже понял, что нет смысла использовать это решение, но где же ответ то на вопрос? "Вот, он не знает, что с пустым паролем подключения запрещены, значит он неуч". "Это не понятия, учи матчасть" и прочие весёлости, вроде стрельбы из пушки.

Я вижу, что форум и так почти мёртвый. Меня к этому ресурсу привлекло много весьма полезных статей, но нет статей, к сожалению, по самому главному - по брандмауэру и защите сети.

В общем, вы намекаете что RTFM. Хорошо, я буду делать это, как делал тысячу раз до этого. Я столько сделал для своей организации, если бы я был неучем, как мне намекают на этом ресурсе, меня давно бы вышвырнули с работы. Трудно, очень трудно постигать всё самому, хочется попросить совета в Интернете, и тут на одном форуме хейтят, на другом держат за неуча, на третьем вообще банят за справедливые замечания. Я пришёл сюда с радостью и с надеждой, на конструктивные диалоги, на ценные подсказки, уходить отсюда, придётся, видимо, с чувством глубокого разочарования. Извините, что побеспокоил.

Уваров А.С.

В политике можно включить подключение и с пустым паролем.
Вообще можно много что сделать, только вот нужно это не всегда. Если вы сами накрутили такую политику, то кто потом вам виноват? Производитель ПО?

Я включил RDP, но вы наверное забыли, что у нас организация бюджетная и сборная солянка - даже компьютеры с Windows XP попадаются, какое уж тут безопасное подключение?
А в чем проблема? SSL не вчера придумали и в Server 2008 R2, который у вас на скриншотах мелькал, все это есть. И даже с XP работает, только немного с настройками поколдовать надо.

Может быть, тогда вы дадите нам денег на микротики?
У меня складывается ощущение, что я (и не только я) должен вам денег и уже несколько лет не отдаю...

Я не знаю, как там работала служба прокси, но работает до сих пор. И имеет нормальную авторизацию по MAC, чего не имеет раздутый Squid, именно поэтому мы на него и не переходим.
Я вам уже писал, что аутентификация на прокси по MAC - это ерунда (собственно как и по IP). У вас доменная сеть - следовательно можно использовать пользователей и SSO, что squid как раз умеет. Кроме того, это гораздо безопаснее, Kerberos на коленке не ломается, а подменить MAC - дело пары минут, даже для студента-двоечника с журналом "Хакер".

Ну покажите мне, скиньте пару скринов, я и поверю.
Скринов чего? TCP-соединений? Или вы pfSense имеете ввиду? Не покажу, у меня его нет нигде в обозримом пространстве. Но в то, что он не умеет работать с состояниями я не поверю. Читайте документацию.


Запретить по белому адресу доступ к RDP, разрешить доступ только из конкретной подсети (10.0, 20.0, 30.0, 50.0, 60.0) через удаленный рабочий стол, а также всяким службам, вроде DNS.
Я кажется конкретно намекнул, что мне нужно. Запретить по белому адресу доступ к RDP, разрешить доступ только из конкретной подсети (10.0, 20.0, 30.0, 50.0, 60.0) через удаленный рабочий стол, а также всяким службам, вроде DNS.
А в чем проблема? Это делается за несколько минут на любом брандмауэре. Это как-бы базовые вещи или вы ждете пока кто-то сделает за вас?

Вы можете конструктивно сказать, хоть раз, безо всяких издёвок и подколок? Написать правила?
Что именно сказать вам конструктивно? "Запретить по белому адресу доступ к RDP" - ну так запретите. Открываем настройки брандмауэра и составляем правило: Если входящий интерфейс - Внешний, протокол ТCP, порт 3389 - запретить. Что не позволяет это сделать без подсказок с форума?

Я уже понял, что нет смысла использовать это решение
В вашем случае, скорее всего да, потому что вы почему-то ждете какой-то волшебной кнопки или волшебного ПО, которое вдруг само все сделает. Это прекрасно видно по-темам с Hyper-V, Veeam и т.д. Да и с Wordpress помнится была аналогичная история.

Не надо скакать, надо делать, разбираться, изучать используемое ПО. Любое из того, с чем вы успели поработать закрывает ваши потребности. Но ничего из этого не работает по двум кликам мышки, везде потребуется изучать и разбираться.


Призрак

Вы же сами сказали, что мне надо изучать и разбираться, что я и делаю.

Состав моего виртуального полигона по изучению сего чуда на данный момент такой:

На хост системе (на домашнем компьютере) адрес 192.168.11.25, маска стандартная, шлюз и DNS 192.168.11.1.

На VMWare Workstation две машины, pfSense и Windows 10.

1. pfSense.

1.1. Адрес em0 192.168.11.21, маска стандартная, шлюз и DNS 192.168.11.1.

1.2. Адрес em1 192.168.130.21, маска стандартная.

2. Windows 10. Адрес 192.168.130.30, маска стандартная, шлюз и DNS 192.168.130.21.

С хост системы мне успешно удалось пробросить порт 3389, на Windows 10. Правда, для этого на хост системе пришлось создать маршрут route add -p 192.168.130.0 netmask 255.255.255.0 192.168.11.21 metric 1. Но в правилах pfSense в пробросе портов потребовалось указать адрес, 192.168.130.30. У меня в сети, допустим, 100 компов. Для того, чтобы подключаться по RDP к каждому мне нужно создавать 100 правил?

И вообще, я подумал, что не нужно нам отдельного железа, всё это чудо можно развернуть на Hyper-V. Хочу сейчас поставить эксперимент, я слышал, что можно авторизовать это чудо через RADIUS, затем подключить к LDAP и ворочать уже группами AD в Squid Guard.

Уваров А.С.

Правда, для этого на хост системе пришлось создать маршрут route add -p 192.168.130.0 netmask 255.255.255.0 192.168.11.21 metric 1
И сразу вопрос, а зачем, если вы пробросили порт, вам 130 сеть? Тем более что она не должна светиться наружу, а у вас похоже что светится.

Проброс портов делается так: Пишем правило, что все пакеты пришедшие на порт 3389 внешнего интерфейса 192.168.11.21 нужно отправить на адрес 192.168.130.30 порт 3389. Это действие называется DNAT, т.е. подмена адреса назначения.

Также нужно второе правило SNAT, которое будет для обратных пакетов заменять адрес источника 192.168.130.30 на адрес внешнего интерфейса 192.168.11.21, либо для внутренней подсети должен быть включен маскарадинг (который делает тоже самое, только немного иначе).

У меня в сети, допустим, 100 компов. Для того, чтобы подключаться по RDP к каждому мне нужно создавать 100 правил?
Именно так. Либо кидайте VPN к внутренней сети и ходите по внутренним адресам. Либо пробрасываете наружу какой-либо сервер, а дальше ходите уже через него.

Хочу сейчас поставить эксперимент, я слышал, что можно авторизовать это чудо через RADIUS, затем подключить к LDAP и ворочать уже группами AD в Squid Guard.
Зачем вам RADIUS? Это вообще из другой оперы, у вас есть AD (тот же LDAP) и Kerberos, который много чего умеет, но самое вкусное - это SSO - Технология единого входа (англ. Single Sign-On) - т.е. пользователь вводит пароль один раз - при входе в систему, а дальше все происходит для него прозрачно, куда нужно - он попадает, куда не нужно - не попадает.

А то, что вы написали - это очередной монстр Франкенштейна, который может и заработает, только лучше бы он этого не делал.


Призрак

И сразу вопрос, а зачем, если вы пробросили порт, вам 130 сеть? Тем более что она не должна светиться наружу, а у вас похоже что светится.
Потому - что без этого у меня не было подключения по rdp. Ну и где тут ваши SNAT и DNAT? Это на микротике есть, да, а тут нет. Попробуйте сами, только с маршрутом у вас получится. Даже если и так, то адрес источника и порт любой.

Призрак

И тут не понял, как этот сертификат добавить, если он уже у меня существует на машине.

Уваров А.С.

Потому - что без этого у меня не было подключения по rdp.
Хост ничего не знает про 130 сеть и знать не должен, вы должны подключаться к 192.168.11.21:3389, а попадать на 192.168.130.30:3389, напрямую к 192.168.130.30:3389 вы подключаться не должны (и в реальном сценарии не сможете, т.к. приватные адреса не маршрутизируются в интернет).

Ну и где тут ваши SNAT и DNAT?
Спрятаны под графическим интерфейсом. Без них вы не сможете ни пробросить порт, ни организовать выход в интернет.

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

Уваров А.С.

И тут не понял, как этот сертификат добавить, если он уже у меня существует на машине.
А что это вообще за сертификат и для чего?

Призрак

А что это вообще за сертификат и для чего?
У меня на машине есть сертификаты для подключения к OpenVPN серверу на Debian для того, чтобы заходить на рабочую машину. Сертификаты я генерировал на сервере OpenVPN. Вот теперь я хочу добавить в pfSense сертификат клиента, чтобы с его помощью попробовать подключиться к серверу, но не знаю как.

Уваров А.С.

Сертификаты для OpenVPN добавляются не здесь, а в настройках OpenVPN.

Призрак

#12
08 Апрель 2019, 20:44 Последнее редактирование: 08 Апрель 2019, 20:51 от Призрак
Сертификаты для OpenVPN добавляются не здесь, а в настройках OpenVPN.
Там где OpenVPN идёт отсылка туда, в создание или импорт. Пытался импортировать сертификат, мне посоветовали как, так и не смог, какая - то лажа.

В общем, я понял, что пока это решение не для нашей организации, вы правы. Зачем тогда новые серверы? На них я развернул Hyper-V со всем необходимым. Когда, повторяюсь, придут микротики (кстати, посоветуйте пожалуйста модель, которую следует заказывать), то я сделаю всё как надо, а пока, как говорится, чем живём, тем и работаем. Брандмауэр я изучу и настрою как следует, в Traffic Inspector пока. Закрою WAN снаружи, только самое необходимое пропущу, как на сервере OpenVPN. Кстати, вы мне тогда подсказали, как настроить брандмауэр правильно, а также на микротике и на веб сервере я настроил, большое вам спасибо.

FreeBSD это очень сложная и капризная система, знаю на своей шкуре. Одни только порты и пакеты чего стоят. Сложная установка и настройка. Кроме того, в упрёк разработчикам можно поставить отсутствие поддержки русского языка в локали, она как то через одно место ставится, но я так и не смог поставить. Ядро может часами собираться, чтобы собрать пакет требуется немало времени, как и скомпилировать ядро. Там сложно, очень сложно поправить слайсы после разметки, почти невозможно, такая UFS. Кроме того, у них есть "сообщество", если вы задали вопрос, будьте уверены, что 100% вас проигнорируют. Тем не менее, многие чудаки считают её основой основ для сайтов, я тоже раньше так считал, пока жизнь не доказала обратное.

То ли дело Debian, это моя самая любимая ось. На ней WEB сервер простой можно развернуть, буквально, за 10 минут.

Уваров А.С.

Когда, повторяюсь, придут микротики (кстати, посоветуйте пожалуйста модель, которую следует заказывать),
Берите RB3011UIAS-RM - оптимально на сегодняшний день.

Тем не менее, многие чудаки считают её основой основ для сайтов, я тоже раньше так считал, пока жизнь не доказала обратное.
НУ в свое время они сильно отстали от Linux, а до этого была неплохая система. Где-то в LJ был блог разработчика Rambler в котором он делился попытками "приручить" FreeBSD, но в итоге ушел на Linux, достаточно познавательное чтиво.

Ядро может часами собираться, чтобы собрать пакет требуется немало времени, как и скомпилировать ядро. Там сложно, очень сложно поправить слайсы после разметки, почти невозможно, такая UFS.
В современной "фряхе" уже давно не так, но навыки работы с этой системой довольно специфичные, знание Linux там сильно не поможет, нужен свой опыт. Поэтому либо нужно серьезно переходить на FreeBSD или вообще ее не трогать.

. Кроме того, у них есть "сообщество", если вы задали вопрос, будьте уверены, что 100% вас проигно
Да нет там почти никого, в этом сообществе. Мало их осталось, кто работает с современной FreeBSD, вот, если хотите, форум одного из наиболее известных спецов по "фряхе" в рунете: https://forum.lissyara.su


Вверх