יום שבת, דצמבר 03, 2016

Office365 mount forbidden

לצערי לא ניתן יותר להשתמש ב davfs2 בשביל לעגון תוכן משותף שיושב על office365 (שיתוף ע"ג sharepoint). גם תוכנות קוד פתוח דוגמת cyberduck נכשלות כשלון חרוץ , קונקי וחבריו לא הצליחו לתת לי פתרון סביר ללא מאמץ.

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

מניסיון העבר sharepoint בדר"כ משתמש בפרוטוקול webdav[s] וזה פשוט עובד מהקופסא, גם בויינדוס וגם בדביאן/רד האט.

יש מערכות שאתה צריך להזדהות פשוט ב http basic באחרות קרברוס ויש כאלה שדורשים OAuth. אבל ככל זה פשוט עובד. 

בעבר הייתי משתמש בcadaver ו mount.davfs2 בשביל העיגון :

עבור webdav אני משתמש ב davf2 ובשביל לעגן את החומר המשותף של VSA תחת 9.17.232.196 מספיק לשמור את פרטי ההתחברות ב  ~/.davf2/secrets כמו :

http://9.17.232.196/sites/VSA/ schenzel myPaSSwoRd

ואז פשוט ב cadaver או mount.

הפעם הדומיין שלי הוא example תחת sharepoint.com:

וניסיתי לשמור את הפרטים בצורה של  :
https://example.sharepoint.com/sites/VSA/ schenzel myPaSSwoRd

וזה נכשל עם שגיאה 403, גם ניסיון גישה באמצעות cadaver או אפילו גישה ל webdavs://example.sharepoint.com/sites/VSA בקונקורר נותן וריאציות של 403.

לאחר מלחמה קצרה גיליתי , שמדובר בשיטת הזדהות מבוססת עוגיות שאינה ממומשת ב davfs2 גם התוכנות שאיתן בדקתי התעלמו מהכותרת שמסבירה את הבעייה:

x-msdavext_error: 917656;
 Access+denied.+Before+opening+files+in+this+location%%2c+you+must+first+browse+to+the+web+site

הפתרון ? להתחבר ל https://example.sharepoint.com  באמצעות משהוא שיוכל לשתף עוגיות עם התוכנה איתה אתם מתחברים לרכיב (נגיד konqueror).

במקרה של konqueror מספיק פשוט להתחבר ל https://example.sharepoint.com ואז ניתן לגשת לכל הדברים המשותפים באמצעות webdavs לדוגמא ל:
webdavs://example.sharepoint.com/sites/VSA 

בגלל שמדובר על עוגיות והדומיין של העוגייה הוא example.sharepoint.com אז ניתן להשתמש בעוגיה עבור כל האתרים המשותפים (שנמצאים תחת sites/SITE_NAME). 

התיקיות שמעניינת אותי  בדר"כ זה (בהנחה שקוראים לsite כ VSA) :

webdavs://example.sharepoint.com/sites/VSA/Shared%20Documents/

במידה ויש לנו notebooks או תיקיות (בממשק השרפויינט) זה יהיה סך הכל תיקייה עם קבצים שאפשר להעתיק מקומית.

יום ראשון, אוקטובר 23, 2016

ביקור רופא בחרו להעביר פרטי התקשרות שנמסרו לשם קבלת טיפול רפואי לחברות צד שלישי

זה הוא סיפורו של ביקור ב"ביקור רופא".

לקוח פנה לביקור רופא http://www.bikurofe.co.il, אחד מאותם מקומות שמפעיל מוקדי חירום וחיילים רבים פונים אליו כשהם חולים. ביקור רופא היא חברה פרטית המפעילה מספר רב של מרפאות ואפילו מספקת פתרון של רופא עד הבית.

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

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


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

לאחר סיום הטיפול התגלה כי חברת "ביקור רופא" העבירה מידע שהתקבל בזמן הטיפול הרפואי של הלקוח ללא אישורו לגוף שלישי (חברת שיווק בשם Shamir Systems הידועה גם כinforu).

בעת העברת המידע וצורת השימוש נחשף חלק מהמידע לגופים נוספים הכוללים חברות תשתיות וחברות המספקות שירותים לגורמים המעורבים.

חברת "ביקור רופא" בחרה בפתרון שלא היה מאובטח, שהוא פתוח לכל, הגישה לא כללה הצפנה כלל (חוזר 5/14 שעוסק במערכת שיתוף מידע בין מוסדות רפואים מדבר על ipsec  ולפחות https להעביר את המידע) ללא ביצוע אימות (הלקוח לא קיבל certificate בשביל לגשת למידע למשל) לא היה שימוש בTwo Factor auth או כל ניסיון לאבטח את המידע.

לחברה שסיפקה יש חותמות SSL (החתומות ע"י comodo עובר *.inforu.co.il), לכן הבחירה בפתרון HTTP תמוהה שבעתיים כי לחברת שמיר מערכות היתה אפשרות להצפין את התעבורה ולספק client certificate ללקוחות ביקור רופא שלא היו נשלחים דרך אותו הערוץ (אלא היו נמסרי בצורה מאובטחת).

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

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

הסמס הגיע ממספר שלא ניתן לחזור אליה (bikurofe),  ככל כתובות אמיתיות למשלוח הודעות SMS הן בעלות מספר טלפון בפורמת E164 (לדוגמא 97239415550). כאשר הלקוח ניסה לשלוח בקשת הסרה, הפעולה נכשלה.

הסמס הכיל היפר קישור אל כתובות שמכילה מזהה יחודי של הביקור מהצורה
 http://i4u.me/zQiti?idd=1234567 שמוביל לדף נחיתה עבור "ביקור רופא".

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

ה idd בהודעה זוהה כמזהה שמערכות המחשוב במרפאה הוציעו בזמן קבלת הטיפול הרפואי. ככל הנראה המספר הוא מאפיין שמזהה בצורה מדוייקת את הלקוח או את אחד ממאפינני הביקור וניתן באמצעותו לאתר ולקבל מידע בהקשר הטיפול הרפואי.

 השרת i4u.me רשום על Shamir Systems מנס ציונה , הידועה גם כ inforu:

Registrant ID: CR176167764
Registrant Name: Ofer Dar
Registrant Organization: Shamir Systems
Registrant Street: P.O Box 2097
Registrant City: Ness Ziona
Registrant State/Province: N/A
Registrant Postal Code: 7412002
Registrant Country: IL
Registrant Phone: +972.39415550
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: oferd@inforu.co.il

כתובת הIP מאוחסנת אצל בזק בין לאומי.

תיאור חשיפת המידע לגורמים שלישים.


המידע הועבר/ נחשף למספר גורמים חלקם רשומים מטה : 

  • חברת השיווק Shamir Systems שמעולם לא קיבלה אישור להעברת מידע אליה או הצטרפות למאגר המידע קיבלה מזהה על טיפול רפואי ומספר טלפון.
  • חברת הסלולאר של הלקוח שקיבל טיפול רפואי (חברות סלולאר רואות את תוכן ההודעות ה סמס כברירת מחדל).
  • חברת עיבוד המידע שחברות התקשורת עובדת איתה של הלקוח ושל חברת התשיתיות ששמיר מערכות עובדים איתם :

    חברות תקשורת פונות לצד ג' על מנת שיתחזקו וייספקו להם פתרונות להעברת הודעות. שני הפרוטוקולים הפופלארים להעברת מידע הוא הSMPP  ו SMS over IP  וקיימות חברות רבות המספקות שירות זה (פיתוח תוכנה או אחזקת פתרון מלא). לעובדי חברות אלו גישה לתוכן ההודעות.
  • חברת התשתית בה inforu משתמשת בשביל לשלוח את ההודעות ה SMS,במידע וקיימות מספר חברות אז כל אחד מהחברות המעורבות וכל מי שנמצא על ציר התעבורה. 
  • חברת בזק בין לאומי (חברת שמיר מערכות לקוחה שלהם) קיבלה את המידע, הבקשה עברה תחת HTTP כל המידע היה חשוף לה.
  • ספק האינטרנט  של הלקוח כי ביקר בביקור רופא , ובגלל שהחיבור עבר ב HTTP בלי שום סוג של אפילו רמז לאבטחה (https) כל מי שהיה בדרך קיבל את המידע הזה.

בשפה לא טכנית - כל אדם שהיה מחובר ברשת התקשורת איתה התחברו ,מהשכנים ברשת ה WiFi ועד כל עובד של החברות המעורבות קיבל גישה למידע.

בשפה קצת טכנית ,

ערוץ הסמס -

  • כאשר יש שימוש בIP להעביר את המידע תוכנת הלקוח אצל השולח פונה אל שרת שמספק שירות (לדגומה SMPP) ובאמצעותו מעבירים הודעה לשרת אצל חברת התקשרות של היעד וזו מעבירה הודעה למשתמש הקצה.
  • כאשר יש שימוש ב SS7, תוכנת הלקוח תייצר הודעת GSM MAP עם invoke והודעת GSM SMS TPDU מסוג SMS-DELVER, בשדה TP-User-Data ימלאו את מלל הסמס. מקטע ה signalng תחת called party יהיה היעד של הודעת הסמס. אם הודעות ה SS7 חוצות קישורים, כל מי שנמצא על הקו (חברות שמספקות בדיקות למשל) מקבלים גישה לתוכן ההודעה אחרת רק כל עובדי החברה שלהם גישה לתשית יש גישה לנתונים.
ערוץ הדאטא -

כאשר  מבצעים dns resolve לשרת i4u.me שרת הDNS שמטפל בבקשה יחפש את שרת ה DNS שמטפל  ב i4u.me והוא יחזיר עבורכם את כתובת ה ip המקושרת לכתבות זו. בשלב זה השרת אליו ניגשתם נחשף למידע זה.

נוצרות מספר בקשות בשביל לדלות את המידע הקיים בדף  שאליו אתם מועברים (מספר בקשות כי אתם גם מורידים קבצי js וגם תזוזה בין מספר שרתים בדרך דרך בקשת window.location). במהלך זה  חברות פרסום נוספות מקבלות מידע (דרך קוד ה Google Analytics המותמע בדף) דרך הבקשה בין i4u.me ל lp.infopage.info, ולבסוף אנו מבצעים התקשרות עם Shamir Systems עם המזהה שלנו.


לחברת שמיר מערכות יכולת לאתר מי מהאנשים ניכנס ובדק את הקישורים שנשלחו אליו:
את צילומי המסך קיבלתי מהתוכנה אותה מספקת inforu מהכתובת הזו:





חברת השיווק inforu/ Shamir Systems קיבלה גישה לפרטים של לקוח שביקש לקבל טיפול רפואי אצל ביקור רופא, הפרטים  שמסר לביקור רופא היו לשם קבלת הטיפול (למרות שמעולם לא אושר העברת מידע) וכמובן שנאסר לחברת שמיר מערכות להשתמש בזה לכל דבר והיא נדרשת ממנה למחוק את הלקוחות האלה מהמאגרים שלה.

כמובן זה ממש מפתיע שביקור רופא העביר את פרטי ההתקשרות שניתנו לשם קבלת טיפול רפואי לחברת שיווק (inforu) וחשף את המידע האישי שלו למספר רב של חברות אחרות.

כיום קיימת מערכת מידע לשיתוף מידע רפואי בין מתקנים, והם בעלי נהלי אבטחת מידע שאמורים להיות מוקפדים על מנת להגן על חשיפת מידע אישי ופרטי.

חברת השיווק זו קיבלה מספר טלפון עובד ביחד עם מזהה ייחודי, ובחרה לשלוח לו הודעות ללא אישורו.
חברת ביקור רופא (www.bikurofe.co.il) פשוט התעלמה מפרטיות הלקוח שביקר בה.

אפשרות הסרה או בקשת רשות להצטרף למאגר לא הייתה.

בעת פרסום הפוסט לא ניתן היה לקבל את תגובות שמיר מערכות ו ביקור רופא.

בוצעו מספר פניות  במייל שאף אחת לא נענתה נכון לתאריך פרסום הפוסט, לאחר מספר ימי המתנה לתשובה הפוסט פורסם.

טל"ח

יום שלישי, אוקטובר 18, 2016

WISPr v1

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

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

WISPr תוכנן ע"י ה Wi-Fi Alliance והוא דרך לבצע פעולות AAA בשביל לאפשר נדידה (Roaming)  אצל ספקי תשתית על בסיס שירותים אלחוטיים (Wireless Internet Service Providers). כאשר אנו מגיעים לספק שיש לו חוזה התקשרות עם ספק האם שלנו אנו נוכל להתחבר אליו גם ללא חשבון (נדידה ב WiFi).


מוגדרים מספר שלבים בתהליך -

הזדהות משתמש הקצה. 
הזדהות הנקודה החמה (hotspot) אל מול ה שירות הזיהוי (Authentication ו Accounting)
התקשרות בין שירותי הזיהוי דרך יישות ניוד (roaming intermediary authntication and Accounting Server) אל ספקי התשתית.

למשתמש הקצה יש חוזה עם ספק התשתית , ספק זה יחייב את הלקוח ע"י חישוב השימוש שבוצע וזוהה ע"י שירות הזיהויי.


אם זה מזכיר לכם את אחד הספקים הגדולים בעולם שנקרא ipass אתם צודקים כי זו אחת הטכנולוגיות שהם משתמשים בהן, דוגמאות שאנשי הקצה יכולים להכיר זה skype wifi או ספקי תקשורת בהם הלקוחות נותנים חלק מרוחב הפס שלהם לרשתות המכילות את המילה Free Wi-Fi - אלו הם פשוט ספקי תקשורת שמספקים  שימוש נוסף באותו הספק או בשיטה דומה לספק הזה. אחד מהמשתמשים המוכרים למשתמשי הקצה אף מכיל התייחסות מפורשת לipass בתוך ה apk שלו.

בעת התקנה אפליקיית הקצה מותקנת חותמת להזדהות (certificate), ובסיס נתונים שמכיל רשתות אליהם מותר להתחבר.


תהליך ההזדהות -

לאחר שהלקוח התחבר לרשת וי-פי מרשימת הרשתות הרשומות,  התוכנה מבצעת בקשת GET ליעד מוגדר מראש ובודקת את התוכן שחוזר.

אם בתוכן שחוזר קיים WISPr-xml-tag הזדהות ממשיכה אחרת עוצרת,
תוכן לדוגמא:

<HTML> 
<!--
    <?xml version=”1.0” encoding=”UTF-8”?>
    <WISPAccessGatewayParam xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
      xsi:noNamespaceSchemaLocation=”http://www.shekercolshehu.com/WISPAccessGatewayParam.xsd”>
      <Redirect>
        <AccessProcedure>1.0</AccessProcedure>
        <AccessLocation>Totaly not going to rip you off Network</AccessLocation>
        <LocationName>Totaly not going to rip you off</LocationName>
        <LoginURL>https://shekercolshehu.com/login</LoginURL>
        <MessageType>100</MessageType>
        <ResponseCode>0</ResponseCode>
      </Redirect>
    </WISPAccessGatewayParam>
--> 
</HTML>

לקוח הקצה קורא את תוכן המידע שהתקבל (זו אחת הסיבות למה libxml2.so קיים באפליקציית bezeq free wifi), ושולח בקשת חיבור ל LoginURL באמצעות POST ושימוש בחותמת שהותקנה.

זו בדיוק הצורה בה מכשירי הios יכלו להתחבר לAT&T בלי שום בעייה (כי attwifi הוא אחד מהספקי שלקוח ה wispr של אפל עובד איתו כברירת מחדל).

דוגמה לראות מה נקבל תחת שירות כזה היא (הU-A משחק תפקיד חשוב) הכתובת יכולה להיות כל כתובת בשביל לגלות את ההפניה:

$ curl -L -i -H "User-Agent: CaptiveNetworkSupport/1.0 wispr" www.google.com

כתוצאה נקבל את דף ה wispr במקרה שבאמצעותו יש להתחבר אבל אם נקבל באמת את התוכן של www.google.com זה אומר שאין שום wispr בדרך.

WISPr גם מזכיר את האפשרויות האחרות לביצוע הזדהות מול השירות כמו 801.11 (wpa_supplicant)

יום שני, אוקטובר 17, 2016

מאפייני מיקום

כאשר אנו עובדים על תשתיות הרשת פעמים רבות אנו עובדים על נתוני המיקום של המשתמשים בשביל לאפשר שירותי IMS ובשביל לספק שירותים מבוססי מיקום. אחת מדרישות הבסיס היא לאפשר לזהות ולשלוח מאפייני מיקום במקרי חירום  7852.

את נתוני המיקום ניתן לקבל באמצעות בקשת HTTP[s] משרת ה Location Server (LS). נתוני המיקום מתקבלים גם מלקוח הקצה וגם מרשת הסלולאר עצמה.

הממשקים מוגדרים גם ברמת ה TS וגם באמצעות RFCים לדוגמה 6753 (HELD)

קיימים שני פלטים פופלארים.

פלט בינארי בו אנו מקבלים חבילה עם מספר בייתים ובחבילה יש את המיקום ומאפיין המיקום.
בפורמט זה קיימים מספר אפשרויות מיקום :

  • Ellipsoid Poin;
  • Ellipsoid point with uncertainty circle
  • Ellipsoid point with uncertainty ellipse
  • Polygon
  • Ellipsoid point with altitude
  • Ellipsoid point with altitude and uncertainty ellipsoid
  • Ellipsoid Arc
ב 23.032 TS הסוג מקודד ע"י הפורמט בו ה4 הבייטים העליונים ( 8,7,6,5) בבייט הראשון מאפיינים את סוג הצורה :
Bits
4 3 2 1 
0 0 0 0 Ellipsoid Point 
0 0 0 1 Ellipsoid point with uncertainty Circle 
0 0 1 1 Ellipsoid point with uncertainty Ellipse 
0 1 0 1 Polygon 
1 0 0 0 Ellipsoid point with altitude 
1 0 0 1 Ellipsoid point with altitude and uncertainty Ellipsoid 
1 0 1 0 Ellipsoid Arc 

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

כאשר עובדים ב3G וGSM הדבר פשוט, המידע מתקבל דרך פעולות location update ושמירת המיקום בו בוצעה פעולה.

טווחי  האיכון  הם בערך כך :

מבוסס רשת האיכון הוא על בסיס  ה 300 מטר  (תלויי בפריסה ובציוד) , ה 300 מטר מגיע מדרישת ה FCC.
מבוסס מכשיר יכול להיות ברמת המטרים הבודדים.


פלט XMLי, מאופיין כ PIDF-LO.

בחלק משירותי ה WiFi יכולים לשלוח PIDF-LO (מהנתב עצמו) לפי גילוי משתמש, PIDF-LO למחשב שהזדהה כ USER-PC עבור המשתמש user יכול להיות מיוצג כך.



<presence entity="pres:user@subdomain.domain.com" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:gml="http://www.opengis.net/gml" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns="urn:ietf:params:xml:ns:pidf"> <dm:device id="USER-PC"> <gp:geopriv> <gp:location-info> <gml:point srsname="urn:ogc:def:crs:EPSG::4326"> <gml:pos>32.86726 -97.16054</gml:pos> </gml:point> <cl:civicaddress> <cl:flr>2</cl:flr> </cl:civicaddress> </gp:location-info> <gp:usage-rules> <gp:method>Wiremap</gp:method> </gp:usage-rules></gp:geopriv> <dm:deviceid>mac:123456789012</dm:deviceid> <dm:timestamp>2016-10-01T20:57:29Z</dm:timestamp> </dm:device> </presence>

אבל איך זה עובד אם אנחנו לא מסתמכים על הרשת ואין לנו רכיבי GPS או GSM (במקרה שלVoWiFi  למשל).

כשאנו עובדים ב data נקי, וה UE שלנו הוא למשל מחשב המערכות מתבססות על מספר לקוחות.

לקוח ה DHCP שלנו יאפשר שימוש ב4776 .

בנוסף כאשר ה UE זז הרבה או שאנחנו לא יכולים לסמוך על לקוח ה dhcp שיעשה את העבודה אנו משתמשים ב 6442 , ובלקוחות LIS/LoST/held בשביל לקבל מאפייני מיקום מצד שלישי.

בצורה כזאת נתוני המיקום שלנו עוברים תחת משאבי ה SIP כלפי הרשת. וה UE שלנו יוכל לעדכן את הרשת הייכן הוא נמצא.

בצורה כזאת לקוח הSIP שלנו ישלח ויוסיף את מאפייני המיקום שלנו ע"י שימוש ב PIDF-LO

INVITE sips:bob@biloxi.example.com SIP/2.0
   Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
   Max-Forwards: 70
   To: Bob <sips:bob@biloxi.example.com>
   From: Alice <sips:user@atlanta.example.com>;tag=9fxced76sl
   Call-ID: 3848276298220188511@atlanta.example.com
   Geolocation: <cid:target123@atlanta.example.com>
   Geolocation-Routing: no
   Accept: application/sdp, application/pidf+xml
   CSeq: 31862 INVITE
   Contact: <sips:user@atlanta.example.com>
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1

   Content-Type: application/sdp

   ...Session Description Protocol (SDP) goes here

   --boundary1

   Content-Type: application/pidf+xml
   Content-ID: <target123@atlanta.example.com>
   <?xml version="1.0" encoding="UTF-8"?>
       <presence
          xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
          xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
          xmlns:gml="http://www.opengis.net/gml"
          xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
          entity="pres:user@atlanta.example.com">
        <dm:device id="target123-1">
          <gp:geopriv>
            <gp:location-info>
              <gml:location>
                <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                  <gml:pos>32.86726 -97.16054</gml:pos>
                </gml:Point>
             </gml:location>
            </gp:location-info>
            <gp:usage-rules>
              <gbp:retransmission-allowed>false
              </gbp:retransmission-allowed>
              <gbp:retention-expiry>2010-11-14T20:00:00Z
              </gbp:retention-expiry>
            </gp:usage-rules>
            <gp:method>802.11</gp:method>
          </gp:geopriv>
          <dm:deviceID>mac:1234567890ab</dm:deviceID>
          <dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
        </dm:device>
      </presence>
   --boundary1--

מערכת יחיסית פופלארית מבצעת זאת כבר המון זמן, היא lync.

מיקום ב isc-dhcp-server

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

יש מספר RFCים שמתארים איך צריך לשלוח מאפיייני civic בבקשות DHCP.

העיקריים הם  :

4776
3825
6225
geopriv-dhcp-lbyr ביחד עם  dhcp-lci-option-03
held 


ב isc-dhcp-server בשביל להפעיל את העברת המידע צריך לאשר את הבקשה ברמת השרת לדוגמה עבור 4776 :

option unknown-99 code 99 = string;
option unknown-99 00:55:53:01:02:49:44:03:06:4D:6F:73:63:6F:77;
הקידוד לפורמט לפי RFC 4776.

את המיקום אפשר להגדיר פר שרת , או אפילו ברמת הsubnet. כמובן שבמקרה שאנו מספקים גישה ע"ג wifi צריך לתמוך ב 6224 ובגישה ל HELD ועדיפות שיהיה לקוח נוסף שיוכל לעדכן מיקום.

בשביל לדרוש לבקש את השדה יש להוסיף ב /etc/dhcp/dhclient.conf את הערך המתאים לפי השם הקנוני או unknown-code כאשר הcode הוא הערך מה RFC לדוגמה : unknown-99 (או geoconf-civic אם נתמך) תחת request או also request.

משום מה לא הצלחתי לראות למה unknown-123  ו 144 לא עבד (פשוט לא נשלח דרך הלקוח).

יום ראשון, אוקטובר 16, 2016

Wi-Fi calling

אז מה זה Wi-Fi Calling ולמה לנו כאנשי תוכנה חופשית זה כה חשוב  ?

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


הרעיון אומר שרכיב התקשורת שלכם (UE) מתחבר לרשת הוי-פי ומשתמש בה כרכיב גישת הרדיו שלה. הדבר מאפשר למכשירי הקצה לקבל תמיכה ברכבות , תעלות, בנייני משרדים וכל מיני מקומות בהם כיסוי הרדיו הרגיל מתקשה ודורש התקנת רכיבים אחרים (GSM-R ברכבות , משדרים מיוחדים בנקודות גישה וכו').

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

הדבר היחיד שאינו ממוש כמו שצריך ברכיבי הסלולאר הוא לקוח ה ipsec שיתאים בצורה טובה לדרישות ה VoWiFi.

השוני העיקר עבורנו המשתמשים של VoWi-Fi (או VoWiFi) מ VoLTE הוא הרמה בה מתחברים לרשת, לנו כלקוחות קצה קל יותר להשתמש ב VoWiFi בגלל הגישה בה כל לקוח (תאורתית) יוכל להפעיל נתב שמאפשר לטלפון הסלולארי שלו להתחבר לרשת במידה וספק השירות אישר את השיטה.


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

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

אז איך זה עובד ?

לרעיון שימוש ב WiFi כרכיב התעבורה היו מספר גילגולים, הנושא הוצג גם ע"י GSMA וגם קיימים RFCים בדבר.

בגרסאות הישנות של הפתרון (לדוגמה ב WISPr) היו מגדירים שהטלפון שלכם יתחבר לרשתות בהם ה SSID הוא קבוע מראש (לדוגמה T-Mobile או tmobile) ואז מבצעים אימות EAP-SIM ומתקשרים ע"י SIP-IMS.

לאחר מספר גילגולים עברו לשימוש של גילוי דינאמי וקבלת הגדרות בזמן אמת ואז חיבור באמצעות רכיבי ה SIP ישירות לשרת (ספק השירות).שימוש בשירותי XCAP ועידכון מאפייני שיחה ע"י פעולות SIP.

ה RFCים מדברים על שלושה גישות :

גישת ה Trusted - בה אנו סומכים על הרשת המארחת (שלנו ), במצב כזה חברת השירות היא בעלת תשתיות ה AP. היא מבצעת את האימות קרוב לנתבים (היא גם יכולה לספק שירותי ANDSQ בשביל לגרום למערכת להתחבר בצורה פשוטה יותר).


                                                             +-------+
                                                             |  IMS  |
                                                             | Core  |
            +-------------+              +-----------+       +-------+
            |             |              |           |           |
            | +--------+  | Flow mapped  |           |           |
            | |IMS APN |  | to VMAC-01   |           |       +-------+
            | |        +-----------------+           |       |IMS APN|
            | |Client  |  |              |           +-------+ P-GW  |
            | +--------+  |              |           |       +-------+
            |             |              |           |
            |             |              |Release 12 |
            |             |              |  TWAG     |
            |             |              |           |       +-------+
            |             |              |           |       |Default|
            |             |              |           +-------+ APN   |
            | +--------+  | Flow mapped  |           |       | P-GW  |
            | |Default |  | to VMAC-02   |           |       +-------+
            | | APN    +-----------------+           |           |
            | |Client  |  |              |           |           |
            | +--------+  |              |           |           |
            +-------------+              +-----------+           |
                                                               XXXXXX
                                                             XX     XXX
                                                            XX        XX
                                                           X           X
                                                          X            X
                                                          X Internet   X
                                                          X            X
                                                          X           XX
                                                           X         XX
                                                            XX    XXXX
                                                             XXXXXX

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

      +--------------+            +----------+          +-------+
      | +----------+ |  IMS-APN   |          |          |       |
      | |    SWu   | |  Traffic   |          |          |       |
      | |  Client  +------------------------------------+       |
      | |          | | Other APN  |          |          | ePDG  |
      | |          | |  traffic   |          |          |       |
      | |          +------------------------------------+       |
      | |          | |            |          |          +-------+
      | +----------+ |            |          |            |  |
      |              |            |          |         S2b|  |S2b
      |     UE       |            |  WLAN    |            |  +---+
      |              |            | Access   |            |      |
      | +----------+ |  LBO       |          |    +-------+   +-------+
      | | Native   | |  Traffic   |          |    |IMS APN|   | Other |
      | |          | |            |          |    |  PGW  |   |  APN  |
      | | Client   +-------------------+     |    |       |   |  PGW  |
      | |          | |            |    |     |    +-------+   +-------+
      | +----------+ |            |    |     |         |          |
      +--------------+            +----------+         |          |
                                       |               |          |
                                       |           +-------+   +-------+
                                       |           |  IMS  |   |  App  |
                                       |           |       |   | Server|
                                       v           +-------+   +-------+


וגישה היברידת המשלבת את שני הדברים:

                                                  +------+   +---------+
                                                  | IMS  |   |  Other  |
                                                  | Core |   |Services |
                                                  +------+   +---------+
                                                     |           |
                                                  +------+   +-------+
       +--------------+      +-----------+        |IMS   |   | Other |
       | +----------+ |      |           |        |P-GW  |   | P-GW  |
       | |    SWu   | |      | +-------+ |        +------+   +-------+
       | |  Client  | |      | |SIPTO  | |           |           |
       | |          | |      | ++NAT   | |           |  +--------+
       | +----------+ |      | +-------+ |           |  |
       |              |      |           |        +------+
       |     UE       +------+   TWAG    |  S2b   | ePDG |
       |              |      |           +--------+      |
       | +----------+ |      |           |        +------+
       | | Native   | |      |           |
       | | Client   | |      |           |
       | |          | |      |           |  S2a   +-------+
       | +----------+ |      |           +--------+Default|
       +--------------+      +-----------+        | PGW   |
                                                  +-------+
                                                    |
                                                    |
                                                    +
                                                 XXXXXXXX
                                                XX      XX
                                                X        X
                                                XInternetX
                                                X        X
                                                XX      XX
                                                 XXXXXXX


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

בצורה כזאת חברות שמספקות MVNO (או ספקי תקשורת רגילים) יכולות להצהיר על הרשת שלהם תחת כתובות DNS, שמות השירותים מוגדרים מראש (כמו במקרה הENUM ).

GSMA הכריז על מספר שירותים אליהם ניתן להתחבר בשביל לקבל גישה לשירותים :

http://epdg.epc.mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org

http://ss.epdg.epc.mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org

http://rcs.mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org

http://mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org

http://bsf.ims.mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org

http://xcap.ims.mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org

http://andsf.ims.mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org


כל אחת מהכתובת בעת משמעות משלה שמאפשרת שימוש במשאבים נוספים.

במהלך החיבור יקבל את המאפיינים של ה Evolved Packet Data Gateway  (ePDG)  שאיתם צריך להתחבר.

במקרה של רשת שאינה בטוחה נפתח ערוץ ipsec :

לקוח הקצה יפתח ערוץ IPSEC/IKEv2 ( 5996 ו 3GPP TS 33.402)   לשרת בשביל שנוכל להשתמש במשאבי הרשת. ההזדהות (NAI) תהיה במבנה של IMSI@Realm (או מזהה מכשיר תחת realm) וזה ימולא תחת ה IDi בשדה ה IDr נמלא את ה APN שצריך להתחבר בתוך ה ePDG .

לאחר שיבוצע אימות כלפי ה ePDG ונקבל אישור לפתיחת session לאחר מכן לקוח ה SIP-IMS שלנו יבצע invite לקבל שירות.

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

במקרה של רשת מאובטחת לא מקימים תעלה, האימות מתבצע קרוב ל חיבור ל AP ע"י אחד מאפשרויות האימות מבוססי ה EAP, לבסוף לקוח הסיפ יבצע register בשביל להתחיל להשתמש במשאבי הרשת.


הכתובת config.rcs.pub.3gppnetwork.org מאפשר ממשק HTTP לקבל את מאפייני החיבור (זה rcs רגיל) , xcap הוא אותו ה xcap שאנו משתמשים ברכיבי ה SIP כאשר אנו מדברים עם רשתות LTE ו 3G. לצערי הרב ktp ו linphone לא מציגים דרך קלה לעבוד עם xcap.


בצד הלקוח -

בשביל שנוכל להשתמש באפשרויות האלה אנו נצטרך לקוח wpa_suppliant עדכני , לקוח SIP ולקוח ipsec איתו נוכל להתחבר לרשת רכיב חומרה שיודע לקרוא כרטיסי SIM או פשוט מכשיר סלולאר שיודע לתמוך ב WiFi Calling ו LTE.

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

אני מאמין ש linphone ידע להתמודד טוב עם SIP-IMS  ב VoWiFi עם המגבלות הבאות :

אני חושב שהתמיכה ב SMS over IP תהיה לוקה בחסר (יש תמיכה ב 3428 ונראה לי גם ב 4976 אבל לא בטוח שיש תמיכה בכל מה שתחת TS.2431) , הודעות חירום לא יעבדו (כי זה לא מוגדר) אבל פעולות של USSD ככל הנראה כי יעבדו.

מפתחי אפליקציות קצה  יכולים לראות את דרישות ה IMS בRFC ולממש את IR.92 (מה שיאפשר לעבוד גם ב VoLTE וגם ב VoWifi).

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

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

רכיב התקשורת (UE) שלנו יחפש קודם כל רשתות שהוא מכיר (ויודע שניתן להתחבר אליהם אם הם trusted), יבצע זאת ע"י מעבר שמות או יחפש רשתות שמאשרות ביצוע הזדהות סים (EAP-AKA/SIM וכו'). אם זה לא עבר יעבור למוד ה untrstursted בו יחפש את הנקודה אליה צריך להתחבר (לפי רשת הסלולאר שלנו כמו t-mobile.com או לפי הכתובות הרשומות תחת 3gppnetwork).

האימות נכון להיום (שמאפשר את שימוש) כולל דברים מבוססי סים (EAP-AKA) אבל גם דברים שאינם דורשים סים (מה שמאפשר לטאבלט ולדביאן שלנו להתחבר לרשת האלחוט באמצעי EAP-TTLS ו EAP-TLS).

במידה וה AP שלנו דורש הזדהות (hybrid mode או Trusted Mode) את חותמות הלקוח שקיבלנו יש לשמור תחת etc/ssl/certs/  ולהתאים את wpa_supplicant והדפדנים לקרוא משם דוגמאות (כמובן לשנות את הערכים לפי מה שקיבלתם מהספק).


network={
      ssid="TRUSTED-GSM-SSID"
      scan_ssid=1
      key_mgmt=WPA-EAP
      pairwise=CCMP TKIP
      group=CCMP TKIP
      eap=TLS
      identity="$(nonuiccid)@blablagsm.tld"
      ca_cert="/etc/certs/cacert.pem"
      client_cert="/etc/certs/client_blablagsm.pem"
      #or 
      #private_key="client_blablagsm.pem"
      #private_key_passwd="secretuserpassword"
   }
או במקרה של TTLS :
network={
      ssid="UNTRUSTED-GSM-SSID"
      key_mgmt=WPA-EAP
      eap=TTLS
      scan_ssid=1
      pairwise=CCMP TKIP
      group=CCMP TKIP 
      anonymous_identity="anon@blablagsm.tld"
      identity="$(nonuiccid)@blablagsm.tld"
      ca_cert="/etc/certs/ca.pem"
      phase2="autheap=TLS"
      ca_cert2="/etc/certs/cacert.pem"
      client_cert2="/etc/certs/client_blablagsm.pem"
      private_key2="key_client_blablagsm.pem"
      private_key2_passwd="secretuserpassword"
   }


בדביאן על מנת לאפשר את האימות מחדש נצטרך להפעיל ע"י בנייה מחדש עם דגלי ה internetworking מופעלים.

לצערי הרב לא ראיתי פתרון IMS לדסקטופ שתומך בכל הדרישות מה שאומר שנצטרך להפעיל מספר שירותים ו"לנחש" מה חסר בשביל סיפוק השירות. 


אבל אני מאמין שלאחר שהשירות כבר קיים בארבעת הספקים הגדולים בארה"ב  ואורנג' העולמית משהוא כבר יתאים את אפליקציות ה GUI הקיימות היום.

בצד השרת -

בצד הePDG נוכל להשתמש במחשבי דביאן רגילים, שמריץ שירותים סטאנדרטיים כמו שרת דיאמטר, שירות DNS, שרת ipsec, שרת xcap, שרת איכון גאוגרפי, שירותי SIP ומחבר לשירותי ה IMS של הרשת או משתמש ב OpenIMSCore (או דומה לו) בשביל לספק את היכולות הנדרשות.


הרשתות שבוחרות בשיטת ה untrusted כמובן חשופות להתקופות רגילות (דוגמה T-Mobile) אבל ההוזלה והיכולת להשתמש בצד שלישי בקלות בשביל לספק שירות פותחת אפשרויות שעולות על הסכנה בהתקפות.