უფასო პროქსი სერვერი საწარმოსთვის დომენის ავტორიზაციის მქონე

pfSense+Squid https ფილტრით + ერთჯერადი შესვლა (SSO) Active Directory ჯგუფის ფილტრირებით

მოკლე ფონზე

კომპანიას სჭირდებოდა პროქსი სერვერის დანერგვა, საიტებზე წვდომის (მათ შორის https) ფილტრაციის უნარით AD-ის ჯგუფების მიხედვით, რათა მომხმარებლებმა არ შეიყვანონ დამატებითი პაროლები და მისი ადმინისტრირება შესაძლებელი იყოს ვებ ინტერფეისიდან. კარგი აპლიკაციაა, არა?

სწორი პასუხი იქნება ისეთი გადაწყვეტილებების ყიდვა, როგორიცაა Kerio Control ან UserGate, მაგრამ როგორც ყოველთვის ფული არ არის, მაგრამ არის საჭიროება.

ეს არის სადაც კარგი ძველი Squid მოდის სამაშველოში, მაგრამ ისევ - სად შემიძლია ვებ ინტერფეისი? SAMS2? მორალურად მოძველებული. ეს არის სადაც pfSense მოდის სამაშველოში.

აღწერა

ეს სტატია აღწერს, თუ როგორ უნდა დააკონფიგურიროთ Squid პროქსი სერვერი.
Kerberos გამოყენებული იქნება მომხმარებლების ავტორიზაციისთვის.
SquidGuard გამოყენებული იქნება დომენური ჯგუფების მიხედვით გასაფილტრად.

მონიტორინგისთვის გამოყენებული იქნება Lightsquid, sqstat და შიდა pfSense მონიტორინგის სისტემები.
ის ასევე გადაჭრის საერთო პრობლემას, რომელიც დაკავშირებულია ერთიანი შესვლის (SSO) ტექნოლოგიის დანერგვასთან, კერძოდ, აპლიკაციებთან, რომლებიც ცდილობენ ინტერნეტში სერფინგს კომპასის ანგარიშის ქვეშ თავიანთი სისტემის ანგარიშით.

მზადება Squid-ის ინსტალაციისთვის

pfSense იქნება მიღებული, როგორც საფუძველი, Ინსტალაციის ინსტრუქცია.

რომლის შიგნით ჩვენ ვაწყობთ ავთენტიფიკაციას თავად firewall-ზე დომენის ანგარიშების გამოყენებით. ინსტრუქციები.

ძალიან მნიშვნელოვანია!

სანამ დაიწყებთ Squid-ის ინსტალაციას, თქვენ უნდა დააკონფიგურიროთ DNS სერვერი pfsense-ში, გააკეთოთ A ჩანაწერი და PTR ჩანაწერი მისთვის ჩვენს DNS სერვერზე და დააკონფიგურიროთ NTP ისე, რომ დრო არ განსხვავდებოდეს დომენის კონტროლერის დროისგან.

და თქვენს ქსელში, უზრუნველყოთ pfSense-ის WAN ინტერფეისის გადასვლის შესაძლებლობა ინტერნეტში, ხოლო ლოკალურ ქსელში მყოფ მომხმარებლებს დაკავშირება LAN ინტერფეისთან, მათ შორის 7445 და 3128 პორტებზე (ჩემს შემთხვევაში 8080).

ყველაფერი მზადაა? დამყარებულია LDAP კავშირი დომენთან pfSense-ზე ავტორიზაციისთვის და დრო სინქრონიზებულია? დიდი. დროა დავიწყოთ ძირითადი პროცესი.

ინსტალაცია და წინასწარი კონფიგურაცია

Squid, SquidGuard და LightSquid დაინსტალირდება pfSense პაკეტის მენეჯერიდან "სისტემის / პაკეტის მენეჯერის" განყოფილებაში.

წარმატებული ინსტალაციის შემდეგ გადადით "სერვისები / Squid Proxy server /" და პირველ რიგში ლოკალური ქეშის ჩანართში დააკონფიგურირეთ ქეშირება, ყველაფერი დავაყენე 0-ზე, რადგან მე ვერ ვხედავ დიდ აზრს საიტების ქეშირებაში, ბრაუზერები ამით დიდ საქმეს აკეთებენ. პარამეტრების დაყენების შემდეგ დააჭირეთ ღილაკს "შენახვა" ეკრანის ბოლოში და ეს მოგვცემს შესაძლებლობას გავაკეთოთ ძირითადი პროქსი პარამეტრები.

ძირითადი პარამეტრები შემდეგია:

ნაგულისხმევი პორტი არის 3128, მაგრამ მე მირჩევნია გამოვიყენო 8080.

პროქსი ინტერფეისის ჩანართში შერჩეული პარამეტრები განსაზღვრავს რომელ ინტერფეისებს მოუსმენს ჩვენი პროქსი სერვერი. ვინაიდან ეს ბუხარი ისეა აგებული, რომ ის ინტერნეტში გამოიყურება, როგორც WAN ინტერფეისი, მიუხედავად იმისა, რომ LAN და WAN შეიძლება იყოს ერთსა და იმავე ლოკალურ ქვექსელზე, გირჩევთ გამოიყენოთ LAN პროქსისთვის.

Loopback საჭიროა sqstat-ის მუშაობისთვის.

ქვემოთ ნახავთ გამჭვირვალე (გამჭვირვალე) პროქსის პარამეტრებს, ასევე SSL ფილტრს, მაგრამ ჩვენ არ გვჭირდება ისინი, ჩვენი პროქსი არ იქნება გამჭვირვალე და 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 პარამეტრში და კრიპტოში ვირჩევთ დაშიფვრის მეთოდს, სამუშაოდ გამოვიყენე rc4 და -out ველში ვირჩევთ სად გამოგიგზავნით ჩვენს მზა საკვანძო ფაილს.
გასაღების ფაილის წარმატებით შექმნის შემდეგ, ჩვენ მას გავაგზავნით ჩვენს pfSense-ში, მე ამისთვის გამოვიყენე Far, მაგრამ თქვენ ასევე შეგიძლიათ ამის გაკეთება როგორც ბრძანებებით, ასევე putty-ით ან pfSense ვებ ინტერფეისის მეშვეობით "დიაგნოსტიკის ბრძანების ხაზის" განყოფილებაში.

ახლა ჩვენ შეგვიძლია შევცვალოთ/შექმნათ /etc/krb5.conf

სადაც /etc/krb5.keytab არის ჩვენ მიერ შექმნილი საკვანძო ფაილი.

დარწმუნდით, რომ შეამოწმეთ კერბეროს ფუნქციონირება კინიტის გამოყენებით, თუ ის არ მუშაობს, აზრი არ აქვს შემდგომ წაკითხვას.

Squid Authentication-ისა და Access List-ის კონფიგურაცია ავტორიზაციის გარეშე

კერბეროსის წარმატებით კონფიგურაციის შემდეგ, ჩვენ დავამაგრებთ მას ჩვენს კალმარზე.

ამისათვის გადადით ServicesSquid Proxy Server-ზე და მთავარ პარამეტრებში გადადით ბოლოში, იქ ვიპოვით ღილაკს "Advanced settings".

მორგებული პარამეტრები (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

სადაც auth_param მოლაპარაკების პროგრამა /usr/local/libexec/squid/negotiate_kerberos_auth - ირჩევს კერბეროს ავთენტიფიკაციის დამხმარეს, რომელიც გვჭირდება.

ყვითელი -s მნიშვნელობით GSS_C_NO_NAME — განსაზღვრავს ნებისმიერი ანგარიშის გამოყენებას საკვანძო ფაილიდან.

ყვითელი -k მნიშვნელობით /usr/local/etc/squid/squid.keytab - განსაზღვრავს ამ კონკრეტული კლავიშის ფაილის გამოყენებას. ჩემს შემთხვევაში, ეს არის იგივე keytab ფაილი, რომელიც ჩვენ შევქმენით, რომელიც დავაკოპირე /usr/local/etc/squid/ დირექტორიაში და დავარქვით სახელი, რადგან კალმარს არ სურდა ამ დირექტორიასთან მეგობრობა, როგორც ჩანს, არ იყო. საკმარისი უფლებები.

ყვითელი -t მნიშვნელობით - არცერთი - გამორთავს ციკლურ მოთხოვნებს დომენის კონტროლერთან, რაც მნიშვნელოვნად ამცირებს მასზე დატვირთვას, თუ 50-ზე მეტი მომხმარებელი გყავთ.
ტესტის ხანგრძლივობისთვის, ასევე შეგიძლიათ დაამატოთ -d კლავიში - ანუ დიაგნოსტიკა, გამოჩნდება მეტი ჟურნალი.
auth_param მოლაპარაკება ბავშვები 1000 - განსაზღვრავს ავტორიზაციის რამდენიმე პროცესის ერთდროულად გაშვება
auth_param negotiate keep_alive on - არ იძლევა ავტორიზაციის ჯაჭვის გამოკითხვის დროს კავშირის გაწყვეტის საშუალებას
acl auth proxy_auth საჭირო - ქმნის და მოითხოვს წვდომის კონტროლის სიას, რომელიც მოიცავს მომხმარებლებს, რომლებმაც გაიარეს ავტორიზაცია
acl nonauth dstdomain "/etc/squid/nonauth.txt" - ჩვენ აცნობებთ კალმარს არაავტიური წვდომის სიის შესახებ, რომელიც შეიცავს დანიშნულების დომენებს, რომლებზეც ყველას ყოველთვის ექნება წვდომა. ჩვენ თავად ვქმნით ფაილს და მის შიგნით შევდივართ დომენებს ფორმატში

.whatsapp.com
.whatsapp.net

Whatsapp არ არის უშედეგოდ გამოყენებული, როგორც მაგალითი - ის ძალიან მკაფიოა ავთენტიფიკაციის მქონე პროქსის მიმართ და არ იმუშავებს, თუ ავტორიზაციამდე დაუშვებელია.
http_access ნებას რთავს nonauth - დაუშვით ამ სიაზე წვდომა ყველას
http_access უარყოფა !auth - ჩვენ ვუკრძალავთ წვდომას არაავტორიზებული მომხმარებლებისთვის სხვა საიტებზე
http_access ავტორიზაციის დაშვება - დაუშვით ავტორიზებული მომხმარებლებისთვის წვდომა.
ესე იგი, თავად კალმარი კონფიგურირებულია, ახლა დროა დავიწყოთ ჯგუფების მიხედვით ფილტრაცია.

SquidGuard-ის კონფიგურაცია

გადადით ServicesSquidGuard Proxy Filter-ზე.

LDAP ოფციებში ჩვენ შევიყვანთ ჩვენი ანგარიშის მონაცემებს, რომლებიც გამოიყენება კერბეროს ავთენტიფიკაციისთვის, მაგრამ შემდეგ ფორმატში:

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_0%2cOU=squid%2cOU=service-groups%2cDC=DOMAIN%2cDC=LOCAL))

შეინახეთ ჩვენი ჯგუფი, გადადით Times-ში, იქ შევქმენი ერთი უფსკრული, რაც იმას ნიშნავს, რომ ის ყოველთვის იმუშავებს, ახლა გადადით სამიზნე კატეგორიებში და შექმენით სიები ჩვენი შეხედულებისამებრ, სიების შექმნის შემდეგ ვუბრუნდებით ჩვენს ჯგუფებს და ჯგუფის შიგნით, გამოიყენეთ ღილაკები ასარჩევად ვინ სად შეიძლება წავიდეს და ვინ სად ვერ წავიდეს.

LightSquid და sqstat

თუ კონფიგურაციის პროცესში ჩვენ შევარჩიეთ loopback squid-ის პარამეტრებში და გავხსენით 7445-ზე წვდომის შესაძლებლობა Firewall-ში როგორც ჩვენს ქსელში, ასევე თავად pfSense-ზე, მაშინ Squid Proxy Reports Diagnostics-ზე გადასვლისას შეგვიძლია მარტივად გავხსნათ sqstat და Lighsquid. ამ უკანასკნელისთვის დაგვჭირდება იმავე ადგილას შევიტანოთ მომხმარებლის სახელი და პაროლი და ასევე არის დიზაინის არჩევის შესაძლებლობა.

დასრულება

pfSense არის ძალიან მძლავრი ინსტრუმენტი, რომელსაც შეუძლია ბევრი რამის გაკეთება - როგორც ტრაფიკის პროქსი, ასევე მომხმარებლის ინტერნეტზე წვდომის კონტროლი მთელი ფუნქციონირების მხოლოდ ნაწილია, მიუხედავად ამისა, საწარმოში 500 მანქანით, ამან გადაჭრა პრობლემა და დაზოგა პროქსის ყიდვა.

იმედი მაქვს, ეს სტატია დაეხმარება ვინმეს პრობლემის გადაჭრაში, რომელიც საკმაოდ აქტუალურია საშუალო და მსხვილი საწარმოებისთვის.

წყარო: www.habr.com