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

pfSense+Squid с https филтриране + Single sign-on (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 в секцията "Система / Мениджър на пакети".

След успешна инсталация отидете на "Services / Squid Proxy server /" и първо в раздела Local Cache конфигурирайте кеширането, зададох всичко на 0, т.к. Не виждам много смисъл в кеширането на сайтове, браузърите вършат чудесна работа с това. След настройка натискаме бутона "Запазване" в долната част на екрана и това ще ни даде възможност да направим основни настройки на проксито.

Основните настройки са както следва:

Портът по подразбиране е 3128, но предпочитам да използвам 8080.

Избраните параметри в раздела Прокси интерфейс определят кои интерфейси ще слуша нашият прокси сървър. Тъй като тази защитна стена е изградена по такъв начин, че да изглежда в Интернет като WAN интерфейс, въпреки че LAN и WAN могат да бъдат в една и съща локална подмрежа, препоръчвам да използвате LAN за прокси.

Необходима е обратна връзка, за да работи sqstat.

По-долу ще намерите настройките Transparent (прозрачен) прокси, както и SSL Filter, но ние не се нуждаем от тях, нашият прокси няма да е прозрачен и за https филтриране няма да заменим сертификата (имаме документооборот, банка клиенти и т.н.), нека просто погледнем ръкостискането.

На този етап трябва да отидем до нашия домейн контролер, да създадем акаунт за удостоверяване в него (можете също да използвате този, който е конфигуриран за удостоверяване на самия pfSense). Ето един много важен фактор - ако възнамерявате да използвате AES128 или AES256 криптиране - поставете отметка в съответните квадратчета в настройките на вашия акаунт.

Ако вашият домейн е много сложна гора с голям брой директории или вашият домейн е .local, тогава е ВЪЗМОЖНО, но не е сигурно, че ще трябва да използвате проста парола за този акаунт, грешката е известна, но може просто да не работи със сложна парола, трябва да проверите конкретен конкретен случай.

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

# 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 е ключовият файл, който създадохме.

Не забравяйте да проверите работата на kerberos с помощта на kinit, ако не работи, няма смисъл да четете по-нататък.

Конфигуриране на удостоверяване на Squid и списък за достъп без удостоверяване

След като успешно конфигурираме kerberos, ще го прикрепим към нашия Squid.

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

В полето Персонализирани опции (преди удостоверяване) въведете:

#Хелперы
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

където auth_param преговаря програма /usr/local/libexec/squid/negotiate_kerberos_auth - избира помощния kerberos за удостоверяване, от който се нуждаем.

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

ключ -k със смисъл /usr/local/etc/squid/squid.keytab - определя да използва този конкретен файл с таблица с ключове. В моя случай това е същият keytab файл, който създадохме, който копирах в директорията /usr/local/etc/squid/ и го преименувах, защото squid не искаше да бъде приятел с тази директория, очевидно нямаше достатъчно права.

ключ -t със смисъл -няма - деактивира цикличните заявки към домейн контролера, което значително намалява натоварването върху него, ако имате повече от 50 потребители.
За времетраенето на теста можете също да добавите ключ -d - т.е. диагностика, ще се показват повече регистрационни файлове.
auth_param преговаря за деца 1000 - определя колко едновременни процеса на оторизация могат да бъдат стартирани
auth_param преговаря keep_alive на - не позволява прекъсване на връзката по време на запитване на веригата за оторизация
acl auth proxy_auth ИЗИСКВА - създава и изисква списък за контрол на достъпа, който включва потребители, преминали оторизация
acl nonauth dstdomain "/etc/squid/nonauth.txt" - информираме squid за nonauth списъка за достъп, който съдържа целеви домейни, до които всеки винаги ще има достъп. Създаваме самия файл, а вътре в него въвеждаме домейни във формата

.whatsapp.com
.whatsapp.net

Whatsapp не е напразно използван като пример - той е много придирчив към проксито с удостоверяване и няма да работи, ако не е разрешен преди удостоверяване.
http_access разрешава nonauth - разреши достъп до този списък на всички
http_access deny !auth - забраняваме достъпа на неоторизирани потребители до други сайтове
http_access позволи удостоверяване - разрешаване на достъп на оторизирани потребители.
Това е всичко, самият калмар е конфигуриран, сега е време да започнете да филтрирате по групи.

Конфигуриране на SquidGuard

Отидете на ServicesSquidGuard Proxy Filter.

В LDAP Options въвеждаме данните на нашия акаунт, използван за kerberos удостоверяване, но в следния формат:

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

Ако по време на процеса на конфигуриране избрахме loopback в настройките на squid и отворихме възможността за достъп до 7445 в защитната стена както в нашата мрежа, така и в самия pfSense, тогава, когато отидем на Diagnostics of Squid Proxy Reports, можем лесно да отворим както sqstat, така и Lighsquid, за последното ще ни трябва На същото място измислете потребителско име и парола, а също така има възможност да изберете дизайн.

Завършване

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

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

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