Gratis proxyserver för företag med domänauthentisering

pfSense+Squid med HTTPS-filtrering + Enkel inloggningsteknik (SSO) med filtrering enligt Active Directory-grupper

Kort bakgrund

Företaget hade behov av att implementera en proxyserver med möjlighet till filtrering av åtkomst till webbplatser (inklusive https) baserat på grupper från AD, så att användare inte behövde ange några ytterligare lösenord, och administrationen kunde ske via ett webbgränssnitt. Något av ett bra krav, eller hur?

Det rätta svaret skulle vara att köpa sådana lösningar som Kerio Control eller UserGate, men som alltid finns det ingen budget, men behovet är där.

Här kommer den gamla goda Squid till vår hjälp, men återigen – var får vi webbgränssnittet ifrån? SAMS2? Det är moraliskt föråldrat. Här kommer pfSense till hjälp.

Beskrivning

I denna artikel kommer vi att beskriva hur man konfigurerar proxyservern Squid.
För användarautentisering kommer Kerberos att användas.
För filtrering baserat på domän-grupper kommer SquidGuard att användas.

För övervakning kommer Lightsquid, sqstat och interna övervakningssystem i pfSense att användas.
Vi kommer även att lösa det vanliga problemet med implementering av teknik för enkel inloggning (SSO), nämligen applikationer som försöker gå på internet med sina systemkonton.

Förberedelse för installation av Squid

Vi kommer att använda pfSense som grund, Installationsguide.

Inuti kommer vi att organisera autentisering mot brandväggen med hjälp av domänkonton. Guide.

Mycket viktigt!

Innan du börjar installera Squid måste du konfigurera DNS servern i pfSense, skapa en A-post och PTR-poster på vår DNS-server och konfigurera NTP så att tiden inte avviker från tiden på domänkontrollern.

Och i ditt nätverk ge WAN-gränssnittet på pfSense möjlighet att gå på internet, samt låta användarna i det lokala nätverket ansluta till LAN-gränssnittet, inklusive på portarna 7445 och 3128 (i mitt fall 8080).

Är allt klart? Har LDAP-kopplingen för autentisering på pfSense ställts in och tiden är synkroniserad? Utmärkt. Dags att gå vidare med huvudprocessen.

Installation och förkonfigurering

Vi installerar Squid, SquidGuard och LightSquid från pfSense paketmanager i avsnittet "System/Paketmanager".

Efter en framgångsrik installation går vi till "Tjänster/Squid Proxy-server/" och börjar först i fliken Local Cache med att konfigurera cache-inställningarna. Jag har ställt in allt till 0, eftersom jag inte ser någon egentlig mening med att cacha webbplatser; det klarar webbläsarna utmärkt själva. Efter inställningarna klickar vi på knappen "Spara" längst ner på skärmen, vilket ger oss möjlighet att genomföra grundläggande proxy-inställningar.

Vi ställer in de grundläggande inställningarna till följande:

Standardporten är 3128, men jag föredrar att använda 8080.

De valda parametrarna i fliken Proxy Interface avgör vilka gränssnitt vår proxy kommer att lyssna på. server. Eftersom denna brandvägg är uppbyggd så att den ser ut mot internet via WAN-gränssnittet, även om LAN och WAN kan befinna sig i samma lokala nätverk, rekommenderar jag att använda LAN för proxy.

Loopback behövs för att sqstat ska fungera.

Nedan hittar du inställningarna för Transparent (transparent) proxy samt SSL-filter, men dessa behöver vi inte; vår proxy kommer att vara icke-transparent och för HTTPS-filtrering kommer vi inte att använda någon certifikatinhämtning (eftersom vi har dokumenthantering, bank-kund m.m.), utan helt enkelt se på handskakningen.

Vid det här steget behöver vi gå till vår domänkontroller, skapa ett konto för autentisering (det går även att använda det konto som vi konfigurerade för autentisering på själva pfSense). En mycket viktig faktor här är—om du planerar att använda AES128 eller AES256-kryptering—att markera motsvarande alternativ i kontoinställningarna.

Om din domän är en ganska komplex skog med många kataloger eller din domän är .local, kan det vara nödvändigt, men inte säkert, att du behöver använda ett enkelt lösenord för detta konto; det är en känd bugg, men med ett komplext lösenord kan det helt enkelt inte fungera, så det måste kontrolleras i varje specifikt fall.

Efter detta formar vi en nyckelfil för Kerberos, öppnar kommandoprompten med administratörsrättigheter på domänkontrollern och skriver in:

# 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

Där vi anger vår FQDN för pfSense, noga observera versaler, i parameter mapuser anger vi vårt domänkonto och dess lösenord, och i kryptovaluta väljer vi krypteringsmetoden; jag använde rc4 för arbetet och i fältet -out väljer vi vart vi skickar vår färdiga nyckelfil.
Efter att nyckelfilen har skapats framgångsrikt skickar vi den till vår pfSense. Jag använde Far för detta, men det går också att göra med kommandon, eller via putty eller genom webgränssnittet pfSense i avsnittet "DiagnostikKommandorad".

Nu kan vi redigera skapa /etc/krb5.conf

där /etc/krb5.keytab är den fil med nycklar vi har skapat.

Kontrollera alltid Kerberus funktionalitet med hjälp av kinit, om det inte fungerar finns det ingen mening att läsa vidare.

Konfigurera autentisering för Squid och åtkomstlistan utan autentisering

Efter att ha konfigurerat Kerberus, kopplar vi det till vår Squid.

För detta, gå till Tjänster Squid Proxy Server och i de grundläggande inställningarna scrolla till botten, där hittar vi knappen "Avancerade inställningar".

I fältet Custom Options (Before Auth) skriver vi in:

#Хелперы
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 — väljer den nödvändiga Kerberus autentisering hjälparen.

Nyckeln -s med värdet GSS_C_NO_NAME — definierar användningen av vilken konto som helst från nyckelns fil.

Nyckeln -k med värdet /usr/local/etc/squid/squid.keytab — definierar att just denna keytab-fil ska användas. I mitt fall är det samma keytab-fil som skapades av oss, som jag kopierade till katalogen /usr/local/etc/squid/ och döpte om, eftersom Squid inte ville samarbeta med den katalogen, uppenbarligen brist på rättigheter.

Nyckeln -t med värdet -t none — inaktiverar cykliska förfrågningar till domänkontrollern, vilket kraftigt minskar belastningen på den om ni har fler än 50 användare.
Under testperioden kan man även lägga till nyckeln -d — dvs diagnostik, fler loggar kommer att skrivas ut.
auth_param negotiate children 1000 — definierar hur många samtidiga autentiseringsprocesser som kan köras
auth_param negotiate keep_alive on — hindrar samband från att brytas under förfrågan av autentiseringskedjan
acl auth proxy_auth REQUIRED — skapar och kräver en åtkomstkontrollista som inkluderar användare som har genomgått autentisering
acl nonauth dstdomain "/etc/squid/nonauth.txt" — meddelar Squid om nonauth åtkomstlistan där domäner som alltid kommer att ha tillgång är listade. Vi skapar själv filen och skriver in domänerna i formatet

.whatsapp.com
.whatsapp.net

Whatsapp används inte förgäves som exempel — den är mycket känslig när det gäller proxyer med autentisering och kommer inte att fungera om den inte tillåts innan autentisering.
http_access allow nonauth — tillåter alla att få åtkomst till denna lista
http_access deny !auth — förhindrar åtkomst för oauktoriserade användare till andra webbplatser
http_access allow auth — ger tillgång till auktoriserade användare.
Nu är din Squid konfigurerad, och det är dags att börja filtrera efter grupper.

Inställning av SquidGuard

Gå till Tjänster SquidGuard Proxy Filter.

I LDAP-alternativ anger vi uppgifterna för vårt konto som används för Kerberos-autentisering, men i följande format:

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

Om det finns mellanslag eller icke-latinska tecken ska hela denna post omslutas av enkla eller dubbla citat:

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

Därefter sätter vi dessa kryssrutor:

För att skära av onödiga DOMAINpfsense DOMAIN.LOCAL som hela systemet är mycket känsligt för.

Nu går vi till Group Acl och knyter våra domänaccessgrupper, jag använder enkla namn som group_0, group_1 och så vidare upp till 3, där 3 betyder endast whiteliståtkomst och 0 betyder att allt är tillåtet.

Grupperna kopplas på följande sätt:

ldapusersearch ldap://dc.domain.local:3268/DC=DOMAIN,DC=LOCAL?sAMAccountName?sub?(&(sAMAccountName=%s)(memberOf=CN=group_0OU=squidOU=service-groupsDC=DOMAINDC=LOCAL))

Vi sparar vår grupp, går till Tider, där jag har skapat ett intervall som betyder alltid, nu går vi tillbaka till Target Categories och skapar listor enligt eget val, efter att listorna skapats går vi tillbaka till våra grupper och i gruppen väljer vi med knapparna vem som kan gå vart.

LightSquid och sqstat

Om vi i inställningarna har valt loopback i Squid och öppnat upp för att gå till 7445 i brandväggen både i vårt nätverk och på själva pfSense, så kan vi utan problem öppna både sqstat och LightSquid i Diagnostik Squid Proxy-rapporter, för det senare behöver vi också skapa ett användarnamn och lösenord där, med möjlighet att välja utseende.

Avslutning

pfSense är ett mycket kraftfullt verktyg som kan erbjuda mycket — både proxytrafik och kontroll av användartillgång till internet är bara en liten del av funktionaliteten. Ändå har det löst problem i ett företag med 500 datorer och gjort att vi sparat in på att köpa proxy.

Jag hoppas att denna artikel kan hjälpa någon att lösa ett ganska aktuellt problem för medelstora och stora företag.

Källa: habr.com