שרת פרוקסי חינם לארגונים עם הרשאת דומיין

pfSense+Squid עם סינון https + כניסה יחידה (SSO) עם סינון קבוצת Active Directory

רקע קצר

החברה נדרשה להטמיע שרת פרוקסי עם יכולת לסנן גישה לאתרים (כולל https) לפי קבוצות מ-AD, כך שהמשתמשים לא יכניסו סיסמאות נוספות, וניתן יהיה לנהל אותם מממשק האינטרנט. אפליקציה טובה, לא?

התשובה הנכונה תהיה לקנות פתרונות כמו Kerio Control או UserGate, אבל כמו תמיד אין כסף, אבל יש צורך.

זה המקום שבו הדיונון הישן והטוב בא להציל, אבל שוב - איפה אני יכול להשיג ממשק אינטרנט? SAMS2? מיושן מבחינה מוסרית. זה המקום שבו pfSense באה להציל.

תיאור

מאמר זה יתאר כיצד להגדיר את שרת ה-proxy Squid.
Kerberos ישמש להרשאת משתמשים.
SquidGuard ישמש לסינון לפי קבוצות דומיינים.

מערכות ניטור Lightsquid, sqstat ו-pfSense פנימיות ישמשו לניטור.
זה גם יפתור בעיה נפוצה הקשורה בהכנסת טכנולוגיית כניסה יחידה (SSO), כלומר יישומים שמנסים לגלוש באינטרנט מתחת לחשבון המצפן עם חשבון המערכת שלהם.

מתכוננים להתקנת סקוויד

pfSense יילקח כבסיס, הוראות התקנה.

בתוכו אנו מארגנים אימות על חומת האש עצמה באמצעות חשבונות דומיין. הוראות.

חשוב מאוד!

לפני שתתחיל להתקין את Squid, עליך להגדיר את שרת ה-DNS ב-pfsense, לעשות עבורו רשומת A ורשומת PTR בשרת ה-DNS שלנו, ולהגדיר את NTP כך שהשעה לא תהיה שונה מהשעה בבקר התחום.

וברשת שלך, ספק את היכולת לממשק ה-WAN של pfSense לעבור לאינטרנט, ולמשתמשים ברשת המקומית להתחבר לממשק ה-LAN, כולל ביציאות 7445 ו-3128 (במקרה שלי 8080).

הכל מוכן? האם חיבור LDAP נוצר עם הדומיין להרשאה ב-pfSense והשעה מסונכרנת? גדול. זה הזמן להתחיל את התהליך העיקרי.

התקנה והגדרה מראש

Squid, SquidGuard ו-LightSquid יותקנו ממנהל החבילות של pfSense בקטע "מנהל מערכת / חבילות".

לאחר התקנה מוצלחת, עבור אל "שירותים / שרת פרוקסי Squid /" וקודם כל, בלשונית מטמון מקומי, תגדיר שמירה במטמון, הגדרתי הכל ל-0, כי אני לא רואה טעם באחסון אתרים במטמון, דפדפנים עושים עבודה מצוינת עם זה. לאחר ההגדרה, לחץ על כפתור "שמור" בתחתית המסך וזה ייתן לנו את ההזדמנות לבצע הגדרות פרוקסי בסיסיות.

ההגדרות העיקריות הן כדלקמן:

יציאת ברירת המחדל היא 3128, אבל אני מעדיף להשתמש ב-8080.

הפרמטרים שנבחרו בלשונית ממשק פרוקסי קובעים באילו ממשקים שרת ה-proxy שלנו יקשיב. מכיוון שחומת אש זו בנויה בצורה כזו שהיא נראית באינטרנט כממשק WAN, למרות ש-LAN ו-WAN יכולים להיות באותה רשת משנה מקומית, אני ממליץ להשתמש ב-LAN עבור ה-proxy.

יש צורך ב-Loopback כדי ש-sqstat יפעל.

למטה תמצאו את הגדרות ה-proxy השקוף (שקוף) וכן מסנן SSL, אבל אנחנו לא צריכים אותם, ה-proxy שלנו לא יהיה שקוף, ולסינון 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 בשביל זה, אבל אתה יכול גם לעשות זאת גם עם פקודות וגם עם מרק או דרך ממשק האינטרנט של pfSense בסעיף "שורת פקודות אבחון".

כעת נוכל לערוך/ליצור /etc/krb5.conf

כאשר /etc/krb5.keytab הוא קובץ המפתח שיצרנו.

הקפידו לבדוק את פעולת ה-kerberos באמצעות kinit, אם זה לא עובד, אין טעם להמשיך לקרוא.

הגדרת אימות דיונון ורשימת גישה ללא אימות

לאחר שהגדרנו את ה-kerberos בהצלחה, נצמיד אותו לדיונון שלנו.

לשם כך, עבור אל 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 negotiate program /usr/local/libexec/squid/negotiate_kerberos_auth - בוחר את עוזר האימות kerberos שאנו צריכים.

מפתח -s עם משמעות GSS_C_NO_NAME - מגדיר את השימוש בכל חשבון מקובץ המפתח.

מפתח -k עם משמעות /usr/local/etc/squid/squid.keytab - קובע להשתמש בקובץ keytab הספציפי הזה. במקרה שלי, זה אותו קובץ keytab שיצרנו, אותו העתקתי לספריית /usr/local/etc/squid/ ושיניתי לו, כי הדיונון לא רצה להיות חבר עם הספרייה הזו, כנראה שלא היו מספיק זכויות.

מפתח -t עם משמעות - לא אף אחד - משבית בקשות מחזוריות לבקר התחום, מה שמפחית מאוד את העומס עליו אם יש לך יותר מ-50 משתמשים.
למשך הבדיקה, ניתן גם להוסיף את מקש -d - כלומר אבחון, יומנים נוספים יוצגו.
auth_param negotiate children 1000 - קובע כמה תהליכי הרשאה בו זמנית ניתן להפעיל
auth_param negotiate keep_alive on - אינו מאפשר לנתק את הקשר במהלך הסקרים של שרשרת ההרשאות
acl auth proxy_auth נדרש - יוצר ודורש רשימת בקרת גישה הכוללת משתמשים שעברו הרשאה
acl nonauth dstdomain "/etc/squid/nonauth.txt" - אנו מודיעים לדיונון על רשימת הגישה nonauth, המכילה תחומי יעד, שאליהם תמיד תתאפשר גישה לכולם. אנחנו יוצרים את הקובץ עצמו, ובתוכו אנחנו מכניסים דומיינים בפורמט

.whatsapp.com
.whatsapp.net

וואטסאפ לא לשווא משמש כדוגמה - זה מאוד בררן לגבי ה-proxy עם אימות ולא יעבוד אם זה לא מותר לפני האימות.
http_access אפשר nonauth - אפשר גישה לרשימה זו לכולם
http_access דחיית !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 מיותר 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))

שמור את הקבוצה שלנו, עבור לטיימס, שם יצרתי פער אחד כלומר תמיד לעבוד, כעת עבור לקטגוריות יעד וליצור רשימות לפי שיקול דעתנו, לאחר יצירת הרשימות אנו חוזרים לקבוצות שלנו ובתוך הקבוצה עם כפתורים אנו בוחרים מי יכול ללכת איפה, ומי לא יכול איפה.

LightSquid ו-sqstat

אם במהלך תהליך ההגדרה בחרנו לולאה בהגדרות squid ופתחנו את היכולת לגשת ל-7445 בחומת האש הן ברשת שלנו והן ב-pfSense עצמה, אז כשנכנסים ל-Squid Proxy Reports Diagnostics, נוכל לפתוח בקלות גם sqstat וגם Lighsquid, עבור האחרון נצטרך באותו מקום, לבוא עם שם משתמש וסיסמה, ויש גם הזדמנות לבחור עיצוב.

השלמה

pfSense הוא כלי חזק מאוד שיכול לעשות הרבה דברים - גם פרוקסי תעבורה וגם שליטה על גישת משתמשים לאינטרנט הם רק חלק קטן מכל הפונקציונליות, עם זאת, בארגון עם 500 מכונות, זה פתר את הבעיה וחסך ב קניית פרוקסי.

אני מקווה שמאמר זה יעזור למישהו לפתור בעיה שהיא די רלוונטית עבור ארגונים בינוניים וגדולים.

מקור: www.habr.com