pfSense+Squid amb filtratge https + inici de sessió únic (SSO) amb filtre de grup Active Directory
Breu resum
L'empresa necessitava implementar un servidor intermediari amb la possibilitat de filtrar l'accés als llocs (inclosos https) per grups d'AD perquè els usuaris no introduïssin cap contrasenya addicional i es puguin administrar des de la interfície web. Bona aplicació, no?
La resposta correcta seria comprar solucions com Kerio Control o UserGate, però com sempre no hi ha diners, però sí una necessitat.
Aquí és on el bon vell Squid ve al rescat, però de nou, on puc obtenir una interfície web? SAMS2? Moralment obsolet. Aquí és on pfSense ve al rescat.
Descripció
Aquest article descriurà com configurar el servidor intermediari Squid.
Kerberos s'utilitzarà per autoritzar usuaris.
SquidGuard s'utilitzarà per filtrar per grups de domini.
Per a la supervisió s'utilitzaran sistemes de monitorització Lightsquid, sqstat i pfSense interns.
També solucionarà un problema comú associat a la introducció de la tecnologia d'inici de sessió únic (SSO), és a dir, les aplicacions que intenten navegar per Internet amb el compte de la brúixola amb el seu compte del sistema.
Preparant la instal·lació de Squid
pfSense es prendrà com a base,
Dins del qual organitzem l'autenticació al mateix tallafoc mitjançant comptes de domini.
És molt important!
Abans de començar a instal·lar Squid, heu de configurar el servidor DNS a pfsense, fer-ne un registre A i un registre PTR al nostre servidor DNS i configurar NTP perquè l'hora no difereixi de l'hora del controlador de domini.
I a la vostra xarxa, proporcioneu la possibilitat que la interfície WAN de pfSense vagi a Internet i que els usuaris de la xarxa local es connectin a la interfície LAN, inclosos els ports 7445 i 3128 (en el meu cas 8080).
Està tot preparat? S'ha establert la connexió LDAP amb el domini per a l'autorització a pfSense i l'hora està sincronitzada? Genial. És hora d'iniciar el procés principal.
Instal·lació i preconfiguració
Squid, SquidGuard i LightSquid s'instal·laran des del gestor de paquets pfSense a la secció "Sistema / Gestor de paquets".
Després de la instal·lació correcta, aneu a "Serveis / Servidor intermediari Squid /" i, en primer lloc, a la pestanya de la memòria cau local, configureu la memòria cau, ho poso tot a 0, perquè No veig gaire sentit als llocs de memòria cau, els navegadors fan una gran feina amb això. Després de configurar, premeu el botó "Desa" a la part inferior de la pantalla i això ens donarà l'oportunitat de fer la configuració bàsica del proxy.
Els paràmetres principals són els següents:
El port predeterminat és 3128, però prefereixo utilitzar 8080.
Els paràmetres seleccionats a la pestanya Interfície proxy determinen quines interfícies escoltarà el nostre servidor intermediari. Com que aquest tallafoc està construït de tal manera que es veu a Internet com una interfície WAN, tot i que la LAN i la WAN poden estar a la mateixa subxarxa local, recomano utilitzar LAN per al proxy.
El loopback és necessari perquè sqstat funcioni.
A continuació trobareu la configuració del proxy transparent (transparent), així com el filtre SSL, però no els necessitem, el nostre proxy no serà transparent, i per al filtratge https no substituirem el certificat (tenim flux de documents, banc clients, etc.), mirem només l'encaixada de mans.
En aquesta etapa, hem d'anar al nostre controlador de domini, crear-hi un compte d'autenticació (també podeu utilitzar el que es va configurar per a l'autenticació al mateix pfSense). Aquí teniu un factor molt important: si teniu intenció d'utilitzar l'encriptació AES128 o AES256, marqueu les caselles adequades a la configuració del vostre compte.
Si el vostre domini és un bosc molt complex amb un gran nombre de directoris o el vostre domini és .local, aleshores és POSSIBLE, però no segur, que haureu d'utilitzar una contrasenya senzilla per a aquest compte, l'error és conegut, però pot simplement no funcionar amb una contrasenya complexa, cal que comproveu un cas concret concret.
Després d'això, creem un fitxer de claus per a kerberos, obrim un indicador d'ordres amb drets d'administrador al controlador de domini i introduïm:
# 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
On indiquem el nostre FQDN pfSense, assegureu-vos de respectar el cas, introduïm el nostre compte de domini i la seva contrasenya al paràmetre mapuser, i en crypto seleccionem el mètode de xifratge, he utilitzat rc4 per treballar i al camp -out seleccionem on enviarem el nostre fitxer de claus acabat.
Després de crear correctament el fitxer de claus, l'enviarem al nostre pfSense, he utilitzat Far per a això, però també podeu fer-ho amb ordres i massilla o mitjançant la interfície web pfSense a la secció "Línia d'ordres de diagnòstic".
Ara podem editar/crear /etc/krb5.conf
on /etc/krb5.keytab és el fitxer de claus que hem creat.
Assegureu-vos de comprovar el funcionament de kerberos amb kinit, si no funciona, no té sentit llegir més.
Configuració de l'autenticació de Squid i la llista d'accés sense autenticació
Havent configurat kerberos correctament, el fixarem al nostre Squid.
Per fer-ho, aneu a ServicesSquid Proxy Server i a la configuració principal baixeu fins a la part inferior, allà trobarem el botó "Configuració avançada".
Al camp Opcions personalitzades (abans de l'autenticació), introduïu:
#Хелперы
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 authon programa de negociació auth_param /usr/local/libexec/squid/negotiate_kerberos_auth - selecciona l'ajudant de Kerberos d'autenticació que necessitem.
Clau -s amb significat GSS_C_NO_NAME — defineix l'ús de qualsevol compte del fitxer de claus.
Clau -k amb significat /usr/local/etc/squid/squid.keytab - determina utilitzar aquest fitxer de pestanyes de clau en particular. En el meu cas, aquest és el mateix fitxer keytab que vam crear, que vaig copiar al directori /usr/local/etc/squid/ i el vaig canviar el nom, perquè el calamar no volia ser amic d'aquest directori, pel que sembla no n'hi havia. prou drets.
Clau -t amb significat -t cap - desactiva les sol·licituds cícliques al controlador de domini, la qual cosa en redueix molt la càrrega si teniu més de 50 usuaris.
Durant la durada de la prova, també podeu afegir la tecla -d, és a dir, diagnòstics, es mostraran més registres.
auth_param negociar nens 1000 - determina quants processos d'autorització simultanis es poden executar
auth_param negociar keep_alive activat - no permet trencar la connexió durant el sondeig de la cadena d'autorització
acl auth proxy_auth OBLIGAT - crea i requereix una llista de control d'accés que inclogui els usuaris que han superat l'autorització
acl nonauth dstdomain "/etc/squid/nonauth.txt" - informem el calamar sobre la llista d'accés no auth, que conté dominis de destinació, als quals tothom tindrà sempre accés. Creem el mateix fitxer, i dins d'ell introduïm dominis en el format
.whatsapp.com
.whatsapp.net
Whatsapp no s'utilitza en va com a exemple: és molt exigent amb el proxy amb autenticació i no funcionarà si no es permet abans de l'autenticació.
http_access permet nonauth - permetre l'accés a aquesta llista a tothom
http_access denegar !auth - prohibim l'accés a altres llocs a usuaris no autoritzats
http_access permet autenticació - Permetre l'accés als usuaris autoritzats.
Ja està, el calamar en si està configurat, ara toca començar a filtrar per grups.
Configuració de SquidGuard
Aneu a Filtre de servidor intermediari de ServicesSquidGuard.
A Opcions LDAP introduïm les dades del nostre compte utilitzades per a l'autenticació kerberos, però en el format següent:
CN=pfsense,OU=service-accounts,DC=domain,DC=localSi hi ha espais o caràcters no llatins, tota aquesta entrada s'hauria d'incloure entre cometes simples o dobles:
'CN=sg,OU=service-accounts,DC=domain,DC=local'
"CN=sg,OU=service-accounts,DC=domain,DC=local"A continuació, assegureu-vos de marcar aquestes caselles:
Per tallar DOMAINpfsense innecessari .LOCAL al qual tot el sistema és molt sensible.
Ara anem a Group Acl i enllacem els nostres grups d'accés al domini, faig servir noms senzills com group_0, group_1, etc. fins a 3, on 3 només és accés a la llista blanca i 0: tot és possible.
Els grups estan enllaçats de la següent manera:
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))desem el nostre grup, aneu a Times, allà vaig crear un buit que significa treballar sempre, ara aneu a Target Categories i creeu llistes al nostre criteri, després de crear les llistes tornem als nostres grups i dins del grup amb botons seleccionem qui pot anar on, i qui no pot on.
LightSquid i sqstat
Si durant el procés de configuració vam seleccionar un loopback a la configuració de squid i vam obrir la possibilitat d'accedir a 7445 al tallafoc tant a la nostra xarxa com al mateix pfSense, aleshores, quan anem a Diagnostics of Squid Proxy Reports, podem obrir fàcilment tant sqstat com Lighsquid, per a aquest últim necessitarem Al mateix lloc, trobar un nom d'usuari i una contrasenya, i també hi ha l'oportunitat d'escollir un disseny.
Terminació
pfSense és una eina molt potent que pot fer moltes coses: tant el proxy de trànsit com el control de l'accés dels usuaris a Internet són només una fracció de tota la funcionalitat, no obstant això, en una empresa amb 500 màquines, això va resoldre el problema i es va estalviar comprant un proxy.
Espero que aquest article ajudi algú a resoldre un problema que és força rellevant per a les empreses mitjanes i grans.
Font: www.habr.com