‏הצגת רשומות עם תוויות GSM. הצג את כל הרשומות
‏הצגת רשומות עם תוויות GSM. הצג את כל הרשומות

יום שלישי, מרץ 06, 2018

מתקפת מניעת שירות

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

בערך מה-20 לחודש פברואר 2018 התחילה מתקפת לוחמה אלקטרונית הפוגעת בשידור אלחוט שפוגע בשירותי 3G ו LTE.

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


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

מכייון שמצד המקבל כמעט ולא תהיה לנו אינדיקציה שיש בעיית שירות (הקליטה נמוכה אבל קיימת), די קשה להיות מודע שיש איזה בעייה.

שמתי לב שקיימים מספר אינדקטורים (פרט לכישלון שיחות נכנסות) ואני מציין אותם פה:

  • כישלון שיחות נכנסות:


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

  • בעיות גלישה כגון RTT מאוד גבוהה (זמן פינג?) :

למעשה כאשר אנו היינו במצב מחובר (ppp הצליח להתחבר ) אנו לא נידע שיש בעייה עד אשר התוכנות שהיו מחוברות ייכשלו.

לדוגמה הkeep alive שלי זיהה זמני RTT הזויים :

64 bytes from 8.8.8.8: icmp_seq=100 ttl=63 time=90147 ms
64 bytes from 8.8.8.8: icmp_seq=101 ttl=63 time=89123 ms
64 bytes from 8.8.8.8: icmp_seq=102 ttl=63 time=88128 ms
64 bytes from 8.8.8.8: icmp_seq=103 ttl=63 time=87109 ms
64 bytes from 8.8.8.8: icmp_seq=105 ttl=63 time=85121 ms
64 bytes from 8.8.8.8: icmp_seq=104 ttl=63 time=86145 ms
64 bytes from 8.8.8.8: icmp_seq=106 ttl=63 time=84109 ms
64 bytes from 8.8.8.8: icmp_seq=107 ttl=63 time=83095 ms
64 bytes from 8.8.8.8: icmp_seq=108 ttl=63 time=82106 ms
64 bytes from 8.8.8.8: icmp_seq=109 ttl=63 time=81086 ms
64 bytes from 8.8.8.8: icmp_seq=110 ttl=63 time=80061 ms
64 bytes from 8.8.8.8: icmp_seq=111 ttl=63 time=79090 ms
64 bytes from 8.8.8.8: icmp_seq=112 ttl=63 time=78089 ms
64 bytes from 8.8.8.8: icmp_seq=113 ttl=63 time=77064 ms
64 bytes from 8.8.8.8: icmp_seq=114 ttl=63 time=76046 ms
64 bytes from 8.8.8.8: icmp_seq=115 ttl=63 time=75024 ms


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

  • הודעות (SMS) :

הודעות SMS הגיעו בין 30 דקות לשעה ליעדן

נבדק ע"י :

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

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

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

  • הודעות (MMS) - MMS בדומה ל גלישת דאטא משתמש באפיק אחר מאפיק הקול (כאשר לא משתמשים ב VoLTE).

נבדק ע"י :

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

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


לסיכום  -

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

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

יום רביעי, אפריל 27, 2016

EIR

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


מאוד בגדול בדרך כלל EIR - Equipment Identity Register היה ישות בתוך רשת ה GSM שאפשרה בדיקה עם הציוד הקצה (UE) איתו אנו משתמשים מותר לו להתחבר לרשת שלנו (וזאת בשונה מהמזהה אותו אנו מקבלים דרך הכרטיס החכם שאומת על ידי הרשת). ככל ה EIR היה בדרך כלל מקומי לספק והכיל רשימה לבנה ורשימה שחורה של ציוד שיכל להתחבר לרשת (יש גם רשימה אפורה) .

העברת מידע על מכשירים חסומים בוצעה דרך בדיקה מול בסיסי נתונים כמו של GSMA ו imeichecker.

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

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