כמה דוגמאות לארגון WiFi ארגוני כבר תוארו. כאן אתאר כיצד יישמתי פתרון דומה ואת הבעיות שנאלצתי להתמודד איתן בעת התחברות למכשירים שונים. נשתמש ב-LDAP הקיים עם משתמשים רשומים, נעלה את FreeRadius ונקבע את WPA2-Enterprise בבקר Ubnt. הכל נראה פשוט. בוא נראה…
קצת על שיטות EAP
לפני שנמשיך במשימה, עלינו להחליט באיזו שיטת אימות נשתמש בפתרון שלנו.
מתוך ויקיפדיה:
EAP היא מסגרת אימות המשמשת לעתים קרובות ברשתות אלחוטיות ובחיבורים מנקודה לנקודה. הפורמט תואר לראשונה ב-RFC 3748 ועודכן ב-RFC 5247.
EAP משמש לבחירת שיטת אימות, העברת מפתחות ועיבוד מפתחות אלה באמצעות יישומי פלאגין הנקראים שיטות EAP. ישנן שיטות EAP רבות, הן מוגדרות עם EAP עצמה והן משוחררות על ידי ספקים בודדים. EAP לא מגדיר את שכבת הקישור, הוא רק מגדיר את פורמט ההודעה. לכל פרוטוקול המשתמש ב-EAP יש פרוטוקול אנקפסולציית הודעות EAP משלו.
השיטות עצמן:
- LEAP הוא פרוטוקול קנייני שפותח על ידי CISCO. נמצאו פגיעויות. כרגע לא מומלץ להשתמש בו
- EAP-TLS נתמך היטב בקרב ספקים אלחוטיים. זהו פרוטוקול מאובטח מכיוון שהוא היורש של תקני SSL. הגדרת הלקוח היא די מסובכת. אתה צריך תעודת לקוח בנוסף לסיסמה. נתמך במערכות רבות
- EAP-TTLS - נתמך באופן נרחב במערכות רבות, מציע אבטחה טובה על ידי שימוש בתעודות PKI רק בשרת האימות
- EAP-MD5 הוא תקן פתוח נוסף. מציע אבטחה מינימלית. פגיע, אינו תומך באימות הדדי וביצירת מפתחות
- EAP-IKEv2 - מבוסס על Internet Key Exchange Protocol גרסה 2. מספק אימות הדדי והקמת מפתח הפעלה בין לקוח לשרת
- PEAP הוא פתרון משותף של CISCO, Microsoft ו-RSA Security כתקן פתוח. זמין באופן נרחב במוצרים, מספק אבטחה טובה מאוד. בדומה ל-EAP-TTLS, דורש רק אישור בצד השרת
- PEAPv0/EAP-MSCHAPv2 - אחרי EAP-TLS, זהו התקן השני בשימוש נרחב בעולם. שימוש ביחסי לקוח-שרת ב-Microsoft, Cisco, Apple, Linux
- PEAPv1/EAP-GTC - נוצר על ידי Cisco כחלופה ל-PEAPv0/EAP-MSCHAPv2. אינו מגן על נתוני אימות בשום צורה. לא נתמך במערכת ההפעלה Windows
- EAP-FAST היא טכניקה שפותחה על ידי סיסקו כדי לתקן את החסרונות של LEAP. משתמש באישורי גישה מוגנת (PAC). לגמרי לא גמור
מכל הגיוון הזה, הבחירה עדיין לא גדולה. נדרשה שיטת האימות: אבטחה טובה, תמיכה בכל המכשירים (Windows 10, macOS, Linux, Android, iOS) ולמעשה, כמה שיותר פשוט יותר טוב. לכן, הבחירה נפלה על EAP-TTLS בשילוב עם פרוטוקול PAP.
עלולה להתעורר השאלה - למה להשתמש ב-PAP? כי הוא משדר סיסמאות בצורה ברורה?
כן זה נכון. תקשורת בין FreeRadius ל- FreeIPA תתקיים בדרך זו. במצב ניפוי באגים, אתה יכול לעקוב אחר אופן שליחת שם המשתמש והסיסמה. כן, ועזוב אותם, רק לך יש גישה לשרת FreeRadius.
אתה יכול לקרוא עוד על העבודה של EAP-TTLS
FreeRADIUS
FreeRadius יועלה ב- CentOS 7.6. אין כאן שום דבר מסובך, אנחנו קובעים את זה בדרך הרגילה.
yum install freeradius freeradius-utils freeradius-ldap -y
גרסה 3.0.13 מותקנת מהחבילות. את האחרון אפשר לקחת
לאחר מכן, FreeRadius כבר עובד. אתה יכול לבטל את ההערה לשורה ב- /etc/raddb/users
steve Cleartext-Password := "testing"
הפעל לשרת במצב ניפוי באגים
freeradius -X
וליצור חיבור לבדיקה מ-localhost
radtest steve testing 127.0.0.1 1812 testing123
קיבלתי תשובה זיהוי גישה-קבל 115 מ-127.0.0.1:1812 עד 127.0.0.1:56081 אורך 20, זה אומר שהכל בסדר. לך על זה.
אנו מחברים את המודול ldap.
ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldap
ומיד נשנה את זה. אנחנו צריכים FreeRadius כדי להיות מסוגלים לגשת ל- FreeIPA
מופעל/ldap
ldap {
server="ldap://ldap.server.com"
port=636
start_tls=yes
identity="uid=admin,cn=users,dc=server,dc=com"
password=**********
base_dn="cn=users,dc=server,dc=com"
set_auth_type=yes
...
user {
base_dn="${..base_dn}"
filter="(uid=%{%{Stripped-User-Name}:-%{User-Name}})"
}
...
הפעל מחדש את שרת הרדיוס ובדוק את הסנכרון של משתמשי LDAP:
radtest user_ldap password_ldap localhost 1812 testing123
עריכה eap in מופעל/eap
כאן אנו מוסיפים שני מקרים של eap. הם יהיו שונים רק בתעודות ובמפתחות. להלן אסביר מדוע זה כך.
מופעל/eap
eap eap-client { default_eap_type = ttls timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = ${max_requests}
tls-config tls-common {
private_key_file = ${certdir}/fisrt.key
certificate_file = ${certdir}/first.crt
dh_file = ${certdir}/dh
ca_path = ${cadir}
cipher_list = "HIGH"
cipher_server_preference = no
ecdh_curve = "prime256v1"
check_crl = no
}
ttls {
tls = tls-common
default_eap_type = md5
copy_request_to_tunnel = no
use_tunneled_reply = yes
virtual_server = "inner-tunnel"
}
}
eap eap-guest {
default_eap_type = ttls timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = ${max_requests}
tls-config tls-common {
private_key_passwotd=blablabla
private_key_file = ${certdir}/server.key
certificate_file = ${certdir}/server.crt
dh_file = ${certdir}/dh
ca_path = ${cadir}
cipher_list = "HIGH"
cipher_server_preference = no
ecdh_curve = "prime256v1"
check_crl = no
}
ttls {
tls = tls-common
default_eap_type = md5
copy_request_to_tunnel = no
use_tunneled_reply = yes
virtual_server = "inner-tunnel"
}
}
עריכה נוספת מופעל/ברירת מחדל באתר. קטעי ההרשאה והאימות הם בעלי עניין.
מופעל/ברירת מחדל באתר
authorize {
filter_username
preprocess
if (&User-Name == "guest") {
eap-guest {
ok = return
}
}
elsif (&User-Name == "client") {
eap-client {
ok = return
}
}
else {
eap-guest {
ok = return
}
}
ldap
if ((ok || updated) && User-Password) {
update {
control:Auth-Type := ldap
}
}
expiration
logintime
pap
}
authenticate {
Auth-Type LDAP {
ldap
}
Auth-Type eap-guest {
eap-guest
}
Auth-Type eap-client {
eap-client
}
pap
}
בסעיף ההרשאה, אנו מסירים את כל המודולים שאיננו צריכים. אנחנו משאירים רק ldap. הוסף אימות לקוח לפי שם משתמש. זו הסיבה שהוספנו שני מקרים של eap למעלה.
Multi EAPהעובדה היא שכאשר מחברים מכשירים מסוימים, נשתמש באישורי מערכת ונציין את הדומיין. יש לנו אישור ומפתח מרשות אישורים מהימנה. באופן אישי, לדעתי, הליך חיבור כזה קל יותר מאשר לזרוק תעודה בחתימה עצמית על כל מכשיר. אבל גם בלי אישורים בחתימה עצמית, זה עדיין לא הסתדר. מכשירי סמסונג ואנדרואיד =< 6 גרסאות לא יכולים להשתמש באישורי מערכת. לכן, אנו יוצרים עבורם מופע נפרד של eap-guest עם אישורים בחתימה עצמית. עבור כל שאר המכשירים, נשתמש ב-eap-client עם אישור מהימן. שם המשתמש נקבע על ידי השדה אנונימי כאשר המכשיר מחובר. רק 3 ערכים מותרים: אורח, לקוח ושדה ריק. כל השאר נזרק. זה יוגדר אצל פוליטיקאים. אני אתן דוגמה קצת מאוחר יותר.
בואו נערוך את הקטעים של הרשאה ואימות ב מותאם לאתר/מנהרה פנימית
מותאם לאתר/מנהרה פנימית
authorize {
filter_username
filter_inner_identity
update control {
&Proxy-To-Realm := LOCAL
}
ldap
if ((ok || updated) && User-Password) {
update {
control:Auth-Type := ldap
}
}
expiration
digest
logintime
pap
}
authenticate {
Auth-Type eap-guest {
eap-guest
}
Auth-Type eap-client {
eap-client
}
Auth-Type PAP {
pap
}
ldap
}
לאחר מכן, עליך לציין במדיניות באילו שמות ניתן להשתמש לכניסה אנונימית. עֲרִיכָה policy.d/filter.
אתה צריך למצוא קווים דומים לזה:
if (&outer.request:User-Name !~ /^(anon|@)/) {
update request {
Module-Failure-Message = "User-Name is not anonymized"
}
reject
}
ולמטה ב-elsif הוסף את הערכים הרצויים:
elsif (&outer.request:User-Name !~ /^(guest|client|@)/) {
update request {
Module-Failure-Message = "User-Name is not anonymized"
}
reject
}
עכשיו אנחנו צריכים לעבור לספרייה אישורים. כאן אתה צריך לשים את המפתח והאישור מרשות אישורים מהימנה, שכבר יש לנו וצריך להפיק אישורים בחתימה עצמית עבור eap-guest.
שנה את הפרמטרים בקובץ ca.cnf.
ca.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = RU
stateOrProvinceNmae = State
localityNmae = City
organizationName = NONAME
emailAddress = [email protected]
commonName = "CA FreeRadius"
אנו כותבים את אותם ערכים בקובץ server.cnf. אנחנו משנים רק
שם נפוץ:
server.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = RU
stateOrProvinceNmae = State
localityNmae = City
organizationName = NONAME
emailAddress = [email protected]
commonName = "Server Certificate FreeRadius"
לִיצוֹר:
make
מוּכָן. קיבלו server.crt и server.key כבר נרשמנו למעלה ב-eap-guest.
ולבסוף, בואו נוסיף את נקודות הגישה שלנו לקובץ client.conf. יש לי 7 כאלה כדי לא להוסיף כל נקודה בנפרד, נכתוב רק את הרשת בה הן נמצאות (נקודות הגישה שלי נמצאות ב-VLAN נפרד).
client APs {
ipaddr = 192.168.100.0/24
password = password_AP
}
בקר Ubiquiti
אנחנו מעלים רשת נפרדת על הבקר. תן לזה להיות 192.168.2.0/24
עבור אל הגדרות -> פרופיל. אנו יוצרים אחד חדש:
אנו כותבים את הכתובת והיציאה של שרת הרדיוס ואת הסיסמה שנכתבה בקובץ clients.conf:
צור שם רשת אלחוטית חדש. בחר WPA-EAP (Enterprise) כשיטת האימות וציין את פרופיל הרדיוס שנוצר:
אנחנו שומרים הכל, מיישמים וממשיכים הלאה.
הקמת לקוחות
נתחיל מהקשה ביותר!
Windows 10
הקושי מסתכם בכך ש-Windows עדיין לא יודעת איך להתחבר ל-WiFi ארגוני דרך דומיין. לכן, עלינו להעלות ידנית את האישור שלנו לחנות האישורים המהימנה. כאן אתה יכול להשתמש גם בחתימה עצמית וגם מרשות האישורים. אני אשתמש בשני.
לאחר מכן, עליך ליצור חיבור חדש. לשם כך, עבור אל הגדרות הרשת והאינטרנט -> מרכז הרשת והשיתוף -> צור והגדר חיבור או רשת חדשה:
הזן ידנית את שם הרשת ושנה את סוג האבטחה. אחרי שנלחץ על לשנות את הגדרות החיבור ובכרטיסייה אבטחה, בחר אימות רשת - EAP-TTLS.
אנו נכנסים לפרמטרים, קובעים את סודיות האימות - לקוחות. בתור רשות אישורים מהימנה, בחר את האישור שהוספנו, סמן את התיבה "אל תוציא הזמנה למשתמש אם השרת אינו מורשה" ובחר את שיטת האימות - סיסמה לא מוצפנת (PAP).
לאחר מכן, עבור להגדרות המתקדמות, סמן סימון על "ציין את מצב האימות". בחר "אימות משתמש" ולחץ על לשמור אישורים. כאן תצטרך להזין username_ldap ו-password_ldap
אנחנו שומרים הכל, מיישמים, סוגרים. אתה יכול להתחבר לרשת חדשה.
לינוקס
בדקתי על אובונטו 18.04, 18.10, פדורה 29, 30.
ראשית, בואו נוריד את התעודה שלנו. לא מצאתי בלינוקס האם אפשר להשתמש בתעודות מערכת והאם יש בכלל חנות כזו.
בואו נתחבר לדומיין. לכן, אנו זקוקים לאישור מרשות האישורים ממנה נרכשה התעודה שלנו.
כל החיבורים נעשים בחלון אחד. בחירת הרשת שלנו:
אנונימי-לקוח
domain - התחום שעבורו מונפקת האישור
אנדרואיד
לא סמסונג
מגרסה 7, בעת חיבור WiFi, אתה יכול להשתמש בתעודות מערכת על ידי ציון הדומיין בלבד:
domain - התחום שעבורו מונפקת האישור
אנונימי-לקוח
סמסונג
כפי שכתבתי למעלה, מכשירי סמסונג לא יודעים להשתמש בתעודות מערכת בחיבור ל-WiFi ואין להם אפשרות להתחבר דרך דומיין. לכן, עליך להוסיף באופן ידני את תעודת השורש של רשות האישורים (ca.pem, אנחנו לוקחים אותו בשרת Radius). כאן ייעשה שימוש בחתימה עצמית.
הורד את האישור למכשיר שלך והתקן אותו.
התקנת תעודה
במקביל, תצטרך להגדיר את דפוס פתיחת המסך, קוד PIN או סיסמה, אם היא עדיין לא מוגדרת:
הראיתי גרסה מסובכת של התקנת תעודה. ברוב המכשירים, פשוט לחץ על האישור שהורדת.
כאשר האישור מותקן, תוכל להמשיך לחיבור:
אישור - ציין את זה שהותקן
משתמש אנונימי - אורח
MacOS
מכשירי אפל מחוץ לקופסה יכולים להתחבר רק ל-EAP-TLS, אבל אתה עדיין צריך לזרוק עליהם אישור. כדי לציין שיטת חיבור אחרת, עליך להשתמש ב-Apple Configurator 2. בהתאם, עליך להוריד אותו תחילה למק, ליצור פרופיל חדש ולהוסיף את כל הגדרות ה-WiFi הדרושות.
Apple
הזן את שם הרשת שלך כאן
סוג אבטחה - WPA2 Enterprise
סוגי EAP מקובלים - TTLS
שם משתמש וסיסמא - השאר ריקים
אימות פנימי - PAP
זהות חיצונית-לקוח
לשונית אמון. כאן אנו מציינים את הדומיין שלנו
את כל. ניתן לשמור, לחתום ולהפיץ את הפרופיל למכשירים
לאחר שהפרופיל מוכן, עליך להוריד אותו לפרג ולהתקין אותו. במהלך תהליך ההתקנה, יהיה עליך לציין את usernmae_ldap ואת password_ldap של המשתמש:
iOS
התהליך דומה ל-macOS. אתה צריך להשתמש בפרופיל (תוכל להשתמש באותו פרופיל כמו עבור macOS. כיצד ליצור פרופיל ב-Apple Configurator, ראה למעלה).
הורד פרופיל, התקן, הזן אישורים, התחבר:
זה הכל. הקמנו שרת Radius, סנכרנו אותו עם FreeIPA, ואמרנו ל-Ubiquiti APs להשתמש ב-WPA2-EAP.
שאלות אפשריות
בתוך: איך מעבירים פרופיל/תעודה לעובד?
אודות: אני מאחסן את כל התעודות/פרופילים ב-ftp עם גישה לאינטרנט. העלתה רשת אורחים עם הגבלת מהירות וגישה לאינטרנט בלבד, למעט ftp.
האימות נמשך יומיים, לאחר מכן הוא מאופס והלקוח נותר ללא אינטרנט. זֶה. כאשר עובד רוצה להתחבר ל-WiFi, הוא מתחבר תחילה לרשת האורחים, ניגש ל-FTP, מוריד את התעודה או הפרופיל שהוא צריך, מתקין אותו ואז יכול להתחבר לרשת הארגונית.
בתוך: למה לא להשתמש בסכימה עם MSCHAPv2? היא בטוחה יותר!
אודות: ראשית, סכימה כזו עובדת היטב על NPS (מערכת מדיניות רשת של Windows), ביישום שלנו יש צורך להגדיר בנוסף את LDAP (FreeIpa) ולאחסן גיבוב סיסמא בשרת. לְהוֹסִיף. לא מומלץ לבצע הגדרות, כי. זה יכול להוביל לבעיות שונות של סנכרון האולטרסאונד. שנית, ה-hash הוא MD4, כך שהוא לא מוסיף הרבה אבטחה.
בתוך: האם ניתן לאשר מכשירים לפי כתובות מק?
אודות: לא, זה לא בטוח, תוקף יכול לשנות כתובות MAC, ועוד יותר מכך אישור על ידי כתובות MAC אינו נתמך במכשירים רבים
בתוך: מה בדרך כלל להשתמש בכל התעודות האלה? אתה יכול להצטרף בלעדיהם?
אודות: אישורים משמשים להרשאת השרת. הָהֵן. בעת החיבור, המכשיר בודק אם זה שרת שניתן לסמוך עליו או לא. אם כן, האימות ממשיך, אם לא, החיבור נסגר. ניתן להתחבר ללא אישורים, אך אם תוקף או שכן יגדיר שרת רדיוס ונקודת גישה עם שם זהה לשלנו בבית, הוא יכול בקלות ליירט את האישורים של המשתמש (אל תשכח שהם מועברים בטקסט ברור). וכאשר נעשה שימוש בתעודה, האויב יראה ביומנים שלו רק את שם המשתמש הפיקטיבי שלנו - אורח או לקוח ושגיאת סוג - אישור CA לא ידוע
קצת יותר על macOSבדרך כלל ב-macOS, התקנה מחדש של המערכת מתבצעת דרך האינטרנט. במצב שחזור, ה-Mac חייב להיות מחובר ל-WiFi, וגם ה-WiFi הארגוני שלנו וגם רשת האורחים לא יעבדו כאן. באופן אישי, העליתי רשת אחרת, ה-WPA2-PSK הרגילה, מוסתרת, רק עבור פעולות טכניות. או שאתה עדיין יכול ליצור כונן הבזק USB הניתן לאתחול עם המערכת מראש. אבל אם הפרג הוא אחרי 2015, עדיין תצטרך למצוא מתאם לכונן הבזק הזה)
מקור: www.habr.com