🥇Безплатен прокси сървър за предприятия с доменна авторизация

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, тогава ВЪЗМОЖНО, но не е сигурно, че ще трябва да използвате прост парола за тази учетна запись. Известен е бъг, но със сложна парола може просто да не работи, трябва да се проверява в конкретния случай.

След всичко това формирaме файл с ключове за kerberos, в контролера на домейна отваряме командния ред с администраторски права и въвеждаме:

# ktpass -princ HTTP/pfsense.domain.local@DOMAIN.LOCAL -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 е създадения от нас файл с ключове.

Обязательно проверьте работата на Kerberos чрез kinit, ако не работи, няма смисъл да четете по-нататък.

Настройка на удостоверяване за Squid и списък за достъп без удостоверяване

След успешно настройване на Kerberos, ще го свържем с нашия Squid.

За целта отидете на Услуги - Squid Proxy Server и в основните настройки намалете страницата до самото дъно, където ще намерим бутона „Разширени настройки“.

В полето за потребителски опции (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 — избира необходимия ни хелпер за удостоверяване с Kerberos.

Ключ -s с значение GSS_C_NO_NAME — определя използването на всяка сметка от файла с ключове.

Ключ -k с значение /usr/local/etc/squid/squid.keytab — определя използването именно на този ключов файл. В моя случай това е същият форматиран от нас ключов файл, който копирах в директория \/usr\/local\/etc\/squid\/ и преименувах, тъй като 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" — уведомяваме Squid за списъка за достъп nonauth, в който са домейните, за които винаги ще е разрешен достъп на всички. Сами създаваме файла и в него вписваме домейни във формат

.whatsapp.com\n.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 DOMAIN.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_0OU=squidOU=service-groupsDC=DOMAINDC=LOCAL))

Запазваме нашата група, преминаваме в Times, там създадох един времеви интервал, означаващ работа по всяко време, след това преминаваме в Target Categories и създаваме списъци по свое усмотрение, след създаването на списъците се връщаме в нашите групи и в рамките на групата с бутоните избираме кой къде може и кой къде — не.

LightSquid и sqstat

Ако по време на настройването сме избрали лупбек в настройките на сквида и сме отворили възможността да влизаме на 7445 в защитната стена, както в нашата мрежа, така и на самия pfSense, то при преминаване в ДиагностикаSquid Proxy Reports ще можем без проблем да отворим и sqstat, и LightSquid, за последния трябва да измислим потребителско име и парола, както и има възможност да изберем оформление.

Завършване

pfSense е много мощен инструмент, който може да прави много неща — както проксирене на трафик, така и контрол на достъпа на потребителите в интернет, това е само част от функционалността. Все пак, в предприятие с 500 машини, това реши проблема и помогна да се спестят средства от закупуването на прокси.

Надявам се тази статия да помогне на някого да реши доста актуален проблем за средни и големи предприятия.

Източник: habr.com