Бясплатны проксі-сервер для прадпрыемства з даменнай аўтарызацыяй

Бясплатны проксі-сервер для прадпрыемства з даменнай аўтарызацыяй

pfSense+Squid з фільтраваннем https + Тэхналогія адзінага ўваходу (SSO) з фільтраваннем па групах Active Directory

Кароткая перадгісторыя

На прадпрыемстве ўзнікла неабходнасць ва ўкараненні проксі-сервера з магчымасць фільтрацыі доступу да сайтаў (у тым ліку https) па групах з AD, каб карыстачы не ўводзілі ніякіх дадатковых пароляў, а адміністраваць можна было з вэб інтэрфейсу. Нядрэнная заявачка, ці не праўда?

Правільным варыянтам адказу было б купіць такія рашэнні як Kerio Control ці UserGate, але як заўсёды грошай няма, а запатрабаванне ёсць.

Тут то да нас і прыходзіць на выручку стары добры Squid, але зноў жа - дзе ўзяць вэб інтэрфейс? SAMS2? Маральна састарэлы. Тут тое і прыходзіць на выручку pfSense.

Апісанне

У дадзеным артыкуле будзе апісаны спосаб налады проксі-сервера Squid.
Для аўтарызацыі карыстальнікаў будзе выкарыстоўвацца Kerberos.
Для фільтрацыі па даменных групах будзе выкарыстоўвацца SquidGuard.

Для маніторынгу будзе выкарыстаны Lightsquid, sqstat і ўнутраныя сістэмы маніторынгу pfSense.
Таксама будзе вырашана частая праблема, звязаная з укараненнем тэхналогіі адзінага ўваходу (SSO), а менавіта прыкладанні, якія спрабуюць хадзіць у інтэрнэт пад улікам компасвоей сістэмнай улікам.

Падрыхтоўка да ўстаноўкі Squid

За аснову будзе ўзяты pfSense, Інструкцыя па ўстаноўцы.

Унутры якога мы арганізуем аўтэнтыфікацыю на сам міжсеткавы экран з дапамогай даменных улікаў. Інструкцыя.

Вельмі важна!

Перад пачаткам усталёўкі Squid неабходна наладзіць DNS сервера ў pfsense, зрабіць для яго запіс A і PTR запісы на нашым DNS серверы і наладзіць NTP так, каб час не адрознівалася ад часу на кантролеры дамена.

А ў вашай сетцы падаць магчымасць WAN інтэрфейсу pfSense хадзіць у інтэрнэт, а карыстачам у лакальнай сетцы падлучацца на LAN інтэрфейс, у тым ліку па порце 7445 і 3128 (у маім выпадку 8080).

Усё гатова? З даменам сувязь па LDAP для аўтарызацыі на pfSense ўстаноўлена і час сінхранізаваны? Выдатна. Час прыступаць да асноўнага працэсу.

Устаноўка і папярэдняя настройка

Squid, SquidGuard і LightSquid усталюем з мэнэджара пакетаў pfSense у падзеле «Сістэма/Менеджэр пакетаў».

Пасля паспяховай усталёўкі пераходзім у "Сэрвісы/Squid Proxy server/" і ў першую чаргу ва ўкладцы Local Cache наладжваем кэшаванне, я выставіў усё па 0, т.к. не бачу асаблівага сэнсу кэшаваць сайты, з гэтым і браўзэры выдатна спраўляюцца. Пасля налады націскаем клавішу «Захаваць» унізе экрана і гэта дасць нам магчымасць вырабляць асноўныя налады проксі.

Асноўныя наладкі прыводзім да наступнага ўвазе:

Бясплатны проксі-сервер для прадпрыемства з даменнай аўтарызацыяй

Порт па змаўчанні 3128, але я аддаю перавагу выкарыстоўваць 8080.

Вылучаныя параметры ва ўкладцы Proxy Interface вызначаюць якія інтэрфейсы будзе слухаць наш проксі сервер. Бо гэты міжсеткавы экран пабудаваны такім чынам, што ў інтэрнэт ён глядзіць WAN інтэрфейсам, нават пры тым што LAN і WAN могуць быць у адной лакальнай падсетцы, рэкамендую для проксі выкарыстоўваць менавіта LAN.

Лупбек патрэбен для працы sqstat.

Ніжэй вы знойдзеце налады Transparent (празрыстага) проксі, а таксама SSL Filter, але яны нам не патрэбныя, наш проксі будзе не празрыстым, а для фільтрацыі https мы не будзем займацца падменай сертыфіката (у нас жа дакументазварот, банк-кліенты і тд), а проста паглядзім на поціск рукі.

На гэтым этапе нам неабходна перайсці ў наш кантролер дамена, стварыць у ім уліковы запіс для аўтэнтыфікацыі (можна выкарыстаць і тую што наладзілі для аўтэнтыфікацыі на сам pfSense). Тут вельмі важны фактар ​​- калі вы маюць намер выкарыстоўваць шыфраванне AES128 або AES256 - прастаўце адпаведныя галачкі ў наладах ўліковага запісу.

У выпадку, калі ваш дамен уяўляе сабою вельмі складаны лес з вялікай колькасцю каталогаў ці ваш дамен .local, то МАГЧЫМА, але не сапраўды, вам прыйдзецца выкарыстаць для гэтага ўліковага запісу просты пароль, баг вядомы, але са складаны паролем можа проста не працаваць, трэба правяраць на канкрэтным прыватным выпадку.

Бясплатны проксі-сервер для прадпрыемства з даменнай аўтарызацыяй

Пасля гэтага ўсяго фармуем файл ключоў для кербероса, на кантролеры дамена адкрываем камандны радок з правамі адміністратара і ўводны:

# ktpass -princ HTTP/[email protected] -mapuser pfsense -pass 3EYldza1sR -crypto {DES-CBC-CRC|DES-CBC-MD5|RC4-HMAC-NT|AES256-SHA1|AES128-SHA1|All} -ptype KRB5_NT_PRINCIPAL -out C:keytabsPROXY.keytab

Дзе паказваем свой FQDN pfSense, абавязкова выконваючы рэгістр, у параметр mapuser уводны наш даменный уліковы запіс і яе пароль, а ў crypto выбіраемы спосаб шыфравання, я выкарыстаў rc4 для працы і ў поле -out выбіраемы куды адправім наш гатовы файл ключоў.
Пасля паспяховага стварэння файла ключоў адправім яго на наш pfSense, я выкарыстаў для гэтага Far, але таксама можна зрабіць гэты як камандамі, так і putty ці праз вэб інтэрфейс pfSense у падзеле "ДыягностыкаКамандны радок".

Цяпер мы можам адрэдагавацьстварыць /etc/krb5.conf

Бясплатны проксі-сервер для прадпрыемства з даменнай аўтарызацыяй

дзе /etc/krb5.keytab гэта створаны намі файл ключоў.

Абавязкова праверце працу кербероса з дапамогай kinit, калі не працуе - далей няма сэнсу чытаць.

Настройка аўтэнтыфікацыі Squid і спісу доступу без аўтэнтыфікацыі

Паспяхова наладзіўшы керберос прыкруцім яго да нашага Squid`у.

Для гэтага перайдзіце ў Сэрвісы Squid Proxy Server і ў асноўных наладах апусціцеся ў самы ніз, там знойдзем кнопачку "Пашыраныя наладкі".

У поле Custom Options (Before Auth) увядзем:

#Хелперы
auth_param negotiate program /usr/local/libexec/squid/negotiate_kerberos_auth -s GSS_C_NO_NAME -k /usr/local/etc/squid/squid.keytab -t none
auth_param negotiate children 1000
auth_param negotiate keep_alive on
#Списки доступа
acl auth proxy_auth REQUIRED
acl nonauth dstdomain "/etc/squid/nonauth.txt" 
#Разрешения 
http_access allow nonauth 
http_access deny !auth
http_access allow auth

uдэ auth_param negotiate program /usr/local/libexec/squid/negotiate_kerberos_auth - выбірае неабходны нам хелпер керберос аўтэнтыфікацыі.

ключ -s са значэннем GSS_C_NO_NAME - Вызначае выкарыстанне любога ўліковага запісу з файла ключа.

ключ -k са значэннем /usr/local/etc/squid/squid.keytab - Вызначае выкарыстоўваць менавіта гэты кейтаб файл. У маім выпадку гэта той жа сфармаваны намі кейтаб файл, які я скапіяваў у дырэкторыю /usr/local/etc/squid/ і пераназваў, таму што з той дырэкторыяй сквід сябраваць не жадаў, мабыць мае рацыю бракавала.

ключ -t са значэннем -t none - адключае цыклічныя запыты да кантролера дамена, што моцна зніжае нагрузку на яго калі ў вас больш за 50 карыстальнікаў.
На час тэсту таксама можна дадаць ключ -d - г.зн. дыягностыка, больш логаў будзе выводзіцца.
auth_param negotiate children 1000 - вызначае колькі адначасовых працэсаў аўтарызацыі можа быць запушчана
auth_param negotiate keep_alive on - не дае разарваць сувязь падчас апытання ланцужкі аўтарызацыі
acl auth proxy_auth REQUIRED - стварае і патрабуе спіс кантролю доступу, які ўключае ў сябе карыстальнікаў, якія прайшлі аўтарызацыю
acl nonauth dstdomain "/etc/squid/nonauth.txt" - Паведамляем сквіда аб спісе доступу nonauth у якім змяшчаюцца дамены прызначэння, да якіх заўсёды будзе дазволены доступ усім. Сам файл ствараем, а ўнутр яго ўпісваем дамены ў фармаце

.whatsapp.com
.whatsapp.net

Whatsapp не дарма выкарыстоўваецца як прыклад - ён вельмі пераборлівы да проксі з аўтэнтыфікацыяй і не будзе працаваць калі яго не дазволіць да аўтэнтыфікацыі.
http_access allow nonauth - дазваляем доступ да дадзенага спісу ўсім
http_access deny !auth - забараняем доступ неаўтарызаваным карыстальнікам да астатніх сайтаў
http_access allow auth - дазваляем доступ аўтарызаваным карыстальнікам.
Усё, сам Сквід у вас настроены, зараз самы час прыступіць да фільтрацыі па групах.

Настройка SquidGuard

Пераходзім у Сэрвісы SquidGuard Proxy Filter.

У LDAP Options уводзім дадзеныя нашага ўліковага запісу, выкарыстоўванай для керберос аўтэнтыфікацыі, але ў наступным фармаце:

CN=pfsense,OU=service-accounts,DC=domain,DC=local

Калі ёсць прабелы ці не лацінскія знакі ўвесь гэты запіс варта заключыць у адзінарныя або падвойныя двукоссі:

'CN=sg,OU=service-accounts,DC=domain,DC=local'
"CN=sg,OU=service-accounts,DC=domain,DC=local"

Далей абавязкова ставім гэтыя галачкі:

Бясплатны проксі-сервер для прадпрыемства з даменнай аўтарызацыяй

Каб адрэзаць непатрэбныя DOMAINpfsense ДАМЕН.LOCALда якіх уся сістэма вельмі адчувальная.

Цяпер пераходзім у Group Acl і прывязваем нашы даменныя групы доступу, я выкарыстоўваю простыя найменні ў духу group_0, group_1 і тд да 3, дзе 3 – доступ толькі ў белы спіс, а 0 – можна ўсё.

Прывязваюцца групы наступным чынам:

ldapusersearch ldap://dc.domain.local:3268/DC=DOMAIN,DC=LOCAL?sAMAccountName?sub?(&(sAMAccountName=%s)(memberOf=CN=group_0%2cOU=squid%2cOU=service-groups%2cDC=DOMAIN%2cDC=LOCAL))

захоўваем нашу групу, пераходзім у Times, тамака я стварыў адзін прамежак які азначае працаваць заўсёды, зараз пераходзім у Target Categories і ствараем спісы па сваім меркаванні, пасля стварэння спісаў вяртаемся ў нашы групы і ўсярэдзіне груп кнопачкамі выбіраемы хто куды можа, а хто куды — не .

LightSquid і sqstat

Калі падчас налад мы выбралі лупбек у наладах Сквіда і адкрылі магчымасць заходзіць на 7445 у фаерволе як у нашай сетцы, так і на самым pfSense, то пры пераходзе ў Дыягностыка Squid Proxy Reports мы без праблем зможам адкрыць і sqstat і Lighsquid, для апошняга трэба будзе тамака жа прыдумаць лагін і пароль, а таксама ёсць магчымасць абраць афармленне.

Завяршэнне

pfSense вельмі магутная прылада, які можа вельмі шмат усяго - і праксіраванне трафіку, і кантроль над доступам карыстачоў у інтэрнэт гэта толькі макулінка ўсяго функцыяналу, тым не менш на прадпрыемстве з 500 машынамі гэта вырашыла праблему і дазволіла зэканоміць на куплі проксі.

Спадзяюся дадзены артыкул дапаможа каму-небудзь вырашыць дастаткова актуальную для сярэдніх і буйных прадпрыемстваў задачу.

Крыніца: habr.com

Дадаць каментар