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

pfSense+Squid с филтриране https + Технология на единен вход (SSO) с филтриране по групи от Active Directory

Кратка предистория

В предприятието възникна нуждата от внедряване на прокси сървър с възможност за филтриране на достъпа до сайтове (включително https) по групи от AD, така че потребителите да не въвеждат никакви допълнителни пароли, а администрирането да става чрез уеб интерфейс. Неплохa идея, нали?

Правилният вариант за отговор би бил да се закупят подобни решения като 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/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 и в основните настройки се спуснете най-надолу, там ще намерите бутон „Разширени настройки“.

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

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

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

.whatsapp.com
.whatsapp.net

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

Настройка на SquidGuard

Преминаваме в Услуги SquidGuard Proxy Filter.

В LDAP Опции въвеждаме данните на нашата сметка, използвана за 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 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

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

Завършване

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

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

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