תגית: security

על אימות זהות בווב, וקצת על OAuth 2.0 ו OpenID Connect

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

אנחנו ניגשים לאנשי השרת – וגם הם לא ממש בטוחים מה לעשות:

  • האם יש משהו לא טוב ב Basic Authentication? הרי “Basic is beautiful” (ע”פ פוקס).
  • אולי עדיף להוסיף כל מיני “טריקים שמקשים”? אולי לחפש ב StackOverflow?

הנה מדריך יפה שמצאתי בגוגל, “The Ultimate Guide Of Mobile Security” של חברת StormPath (לארונה נרכשה ע”י OKTA).
בטוח שיש בחברה הזו מומחי אבטחה גדולים ממני. אין ספק!
מצד שני… זה המדריך האולטימטיבי? האם הוא באמת משרת את צורכי האבטחה של הקורא, או בעיקר עושה On-Boarding מהיר ספציפית לפתרון של StormPath?

גם כשאתם ניגשים למדריך מוכן, כדאי שיהיה קצת מושג – ועל כן הפוסט הבא.
אדבר על אימות שרת-לשרת, מובייל ועל אפליקציה שרצה בדפדפן, על Basic Authentication אבל גם על OAuth 2.0 וקצת על OpenID Connect.

נתחיל מההתחלה: Basic Authentication (בקיצור: BA)

נתחיל במקרה הפשוט ביותר (מבחינת האבטחה): תקשורת שרת-לשרת.

שיטת אימות הזהות (Authentication) הבסיסית ביותר בווב נקראת “Basic Authentication”.
נניח שיש לנו תסריט בו סוכן-נסיעות (להלן “שוקה”) רוצה לתקשר בצורה מאבטחת עם חברת תעופה מסוימת (להלן “שחקים”).

הנה אופן הפעולה:

1. המתכנת של שחקים מייצר מפתח-זיהוי ייחודי וקשה מאוד לניחוש, שיזהה את הלקוח הספציפי – שוקה:

jsa7arpZ8sPZ60YZyZwfD97gf5cHbEBj77VF6nF4

מחרוזת אקראית באורך 40 תווים נחשבת כיום למפתח מספיק חזק.

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

3. כאשר השרת של שוקה פונה לשרת של שחקים, על גבי HTTPS, הוא מוסיף על הבקשות את ה header הבא:

Authorization: Basic anNhN2FycFo4c1BaNjBZWnlad2ZEOTdnZjVjSGJFQmo3N1ZGNm5GNA==

הפרמטר הראשון אומר איזו סוג זיהוי (Authentication) מדובר. במקרה הזה: BA.
הפרמטר השני הוא ה credentials (“אישור ההרשאות”), במקרה הזה: מפתח הזיהוי מקודד ב Base64.

Base64 הוא קידוד של binary-to-text הנדרש על מנת להעביר את המידע על פרוטוקול HTTP בצורה תקינה. הפרוטוקול מצפה לטקסט, ותווים מסוימים יכולים להתפרש אחרת לחלוטין (למשל: שורה ריקה משמעה שהסתיימו ה headers ומתחיל ה body של בקשת ה HTTP).

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

חוזקות:

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

סה״כ, עבור תקשורת שרת-לשרת, בסביבה שאיננה מרובת איומים – ה BA הוא סביר.
נקודת מפתח היא הקושי ליירט תקשורת שרת לשרת (בהנחה שהשרת לא יושב במקום ציבורי ומשתמש ב Wifi / תא סלולארי)

גרסאת ה Web Client

כאשר התקשורת היא בין דפדפן לשרת, ה flow עובד מעט אחרת:

  • אין תקשורת מוקדמת עם המשתמש, ולא שלוחים לו מפתח-זיהוי.
  • המשתמש פונה ל URL הרצוי.
  • השרת שאינו מזהה את המשתמש, מחזיר HTTP Status 401, כלומר: Unauthorized – “אני לא יודע מי אתה”. כמו כן הוא שולח header המסביר באיזו סוג authentication הוא תומך:
WWW-Authenticate: Basic
  • הדפדפן יקפיץ למשתמש חלון להקלדת שם-משתמש וסיסמה.
  • הדפדפן ייצור מחרוזת credentials כ ״שם משתמש:סיסמה״ – יקודד אותה ב Base64 ויעביר אותה על ה Authorization Header בקריאה הבאה:
Authorization: Basic
  • השרת יפתח את הקידוד ויזהה אם יש לו משתמש עם סיסמה שכזו. אם כן – הוא יניח שהבקשה הגיעה מהמשתמש.
  • שם המשתמש והסיסמה ישארו ב cache של הדפדפן לזמן מוגדר (15 דקות?). בכל בקשה לשרת יישלח ה Authorization Header עם הסיסמה.
חוזקות:
  • פרוטוקול פשוט שקל ליישום.
חולשות:
  • שם המשתמש והסיסמה עוברים כ clear text על כל בקשה (Base64 שקול ל clear text). תקשורת בין endpoint (לצורך פוסט זה: ״תחנת קצה״ -כמו מחשבים ניידים או סמארטפונים) לשרת – הרבה יותר קל ליירט מאשר תקשורת שרת לשרת. למשל: התוקף ותחנת הקצה נמצאים על אותה רשת Wifi.
    • אם התקשורת נעשית על גבי HTTP (רחמנא ליצלן!) – אזי גניבת הסיסמה היא פעולת sniffing פשוטה.
  • שם המשתמש והסיסמה נשארים cached בדפדפן. תוקף יכול לעשות שימוש גם הוא ב credentials מבלי שאף אחד יידע (התקפת CSRF).
סה״כ, BA בדפדפן היא שיטה שנחשבת כחלשה למדי לזיהוי מאובטח של המשתמש, והיא איננה מומלצת לשימוש.
גרסאת המובייל

במובייל יש כמה אפשרויות:

  • אפשר לנסות ולהיצמד לגרסת השרת של ה BA: ולשלוח מפתח-זיהוי לכל משתמש – אך זה אפשרי רק עם התקנה ידנית של Certificate (תהליך סזיפי למשתמש) או מערכות ששותלות Agent במכשיר ועושות זאת – בעיקרון מערכות Enterprise שלא ישימות בסביבת Consumers.
  • אפשר לנסות ולהיצמד לגרסת הדפדפן של ה BA: ולשמור את שם המשתמש והסיסמה באחסון המוגן של המכשיר (shared preferences / key chain) – ואז לשלוח אותם כ credentials בכל בקשה.
    שליחת ה credentials, בכל בקשה, ובמיוחד מתוך endpoints היא חולשה משמעותית – ולכן לא ניתן להמליץ על הגישה הזו.

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

הבו לנו OAuth 2.0!

רוב הסיכויים ששמעתם על פרוטוקול 2.0 OAuth (ל Authentication). יש לו שם של פרוטוקול מכובד “Enterprise Level”, אולי הנפוץ ביותר לשימוש היום – ולכן אפשר לסמוך עליו!
המחשבה ש”אני משתמש ב OAuth 2.0 – ולכן אני מאובטח”, היא אולי נעימה – אך לא ממש נכונה.ראשית כל OAuth 2.0 הוא פרוטוקול ל Delegated Access (“ייפוי כח”) ולא ל Authentication (“אימות זהות). הפרוטוקול נבנה על מנת לאפשר “ייפוי כח” למישהו אחר לגשת למידע שבבעלותי אך נשמר על ידי צד שלישי. בתוך ה Protocol מוגדרת “מסגרת ל Authentication” שהיא כללית, ואיננה נחשבת כחזקה במיוחד.

החלק הזה “מפיל” אנשים, אז שימו לב:
מתוך האתר הרשמי של OAuth, קישור: https://oauth.net/articles/authentication
OAuth הוא בעצם פרוטוקול Authorization. הנה הגדרה פורמאלית:
The OAuth 2.0 authorization framework enables a third-party application to obtain limited
access to an HTTP service, either on behalf of a resource owner by orchestrating an
approval interaction between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf.

שימו לב לקשר החזק ל HTTP.

מכיוון Authentication ב OAuth היא רק Framework ולא פרוטוקול – אין הגדרה חד-משמעית ומדויקת כיצד ה Authentication אמורה להתבצע. זה אומר ש:

  • ה Framework משאיר נושאים מסוימים לבחירת המימוש: איך להשתמש ב scopes, איך לבצע endpoint discovery, רישום דינאמי של לקוחות, וכו’.
  • אין בהכרח תאימות בין מימוש א’ למימוש ב’. אם גוגל ופייסבוק מאפשרים חיבור ב OAuth – לא בטוח שאותו מימוש (של Client) יוכל לעבוד מול שניהם.
  • יש מימושים מאובטחים יותר, ומימושים מאובטחים פחות. תו התקן “OAuth” מציין בעיקר את סדר ההתקשרות – אבל מבטיח אבטחה רק במידה מסוימת.
    • למשל: לא נאמר כיצד להעביר את מפתח ההזדהות. ב URL או כ Header? (עדיף Header כי פחות סביר שהמידע הרגיש הזה יצוץ אח”כ בלוגים)
    • כיצד להעביר את המידע בין השחקנים השונים? לכאורה עדיף להצפין את נתוני ה token, אך יש כאלו שמשאירים אותם גלויים כי נוח שה Client יכול לקרוא גם הוא נתונים על המשתמש….
    • הנה רשימת עשרת החולשות הנפוצות ביותר במימושים של OAuth 2.0.

כיצד OAuth 2.0 עובד (בקצרה)

OAuth בעצם מגדיר ארבע אופנים שונים (נקראים Grants) לקבל Token ולהשתמש בו.

ה Token הוא תחליף ל Password, מכיוון שיצירת password במערכות רבות היא סכנת אבטחה ממשית: אנשים נוטים לעשות שימוש חוזר ב passwords שלהם במערכות שונות, ומערכת אחת שנפרצת – מאפשרת גישה למערכות נוספות, לעתים חשובות יותר.

כדי להבין את OAuth כדאי להשקיע דקה ולהכיר את ה”שחקנים” (Roles) המדוברים:Resource Owner

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

Resource Server (נקרא גם בשם המבלבל “protected resource”)
אקרא לו בפוסט גם “שירות B” – השרת שמאכסן את הנתונים של המשתמש, למשל פייסבוק.
Authentication Server
השרת שמולו המשתמש מזדהה, כלומר שם מתבצע תהליך ה Authentication והוא מנפיק Token שמאמת את זהות המשתמש. ברוב המקרים זהו יהיה ה Resource Server עצמו (או שירות B) – אך התקן לא מחייב זאת.

Client
אקרא לו בפוסט גם בשם “שירות A” – השירות שאליו בעצם פונה המשתמש בבקשה לשירות.
שירות זה לקוח של ה Resource Server והוא מבקש ממנו גישה למשאבים השייכים למשתמש, להלן “ייפוי הכח”.

Authorization code grant

זהו כנראה אופן השימוש הנפוץ ביותר ב OAuth. אתחיל בלתאר אותו בצורה “סיפורית”:

עכשיו המשתמש רוצה להתחבר לשירות A (למשל: ל Comeet), שם מופיעה לו אופציה להתחבר בעזרת החשבון הקיים שלו בשירות B, למשל: “Connect with Linkedin”.

המשתמש מקיש על הלינק של “חיבור בעזרת…”, וקופצת חלונית חדשה בדפדפן (יש הנחה שמדובר בדפדפן) בה מתבצע תהליך ה Authentication מול ה Auth. Server, שהוא לרוב בעצם שירות B עצמו (למשל: לינק-אין).

שירות B מציג אלו פריטי מידע (resource) הוא התבקש לחשוף (לעתים זהו רק ה email, לעתים רשימת חברים ויותר) וכאשר המשתמש מאשר – הוא חוזר לאתר המקורי (שירות A) ומקבל אליו גישה.

התוצאה: המשתמש קיבל גישה לשירות A מבלי שהיה צריך להזין בו שם משתמש / סיסמה. לעתים חושבים שלא נוצר שם חשבון – אך לרוב הוא נוצר על בסיס מזהה ייחודי שסיפק שירות B.

עכשיו נחזור על ה flow בצורה יותר טכנית:

לפני שהכל מתחיל, ה Client (למשל “Site”) נרשם אצל Resource Server (למשל: Facebook). כתוצאה מתהליך הרישום ה Client מקבל client_secret (“מפתח זיהוי”) – אותו הוא שומר בצורה מאובטחת.

כעת המשתמש רוצה להתחבר לשירות A:

  • שירות A מבקש מהמשתמש להזדהות, ומאפשר לו לעשות את זה בעזרת שירות B.
  • המשתמש בוחר בשירות B, ומופנה ל Authentication Server המתאים.
    • שירות A סומך על ה Authentication Server לבצע אימות מאובטח מספיק, ולנפק access-token  מתאים.
    • בד”כ מוצג למשתמש אילו נתונים הוא הולך למסור, ולעתים הוא יכול להחליט לא למסור חלק מהנתונים. כל קבוצת נתונים מוגדרת כ scope. על ה redirect URL ה Client ציין אלו scopes הוא מבקש.
    • המשתמש מזדהה בעזרת שם משתמש וסיסמה (או כל אימות אחר) ומאשר את ה scopes.
  • ישנו Redirect חזרה ל Client עליו מופיעים פרטים של הבקשה המקורית ל Authentication – שבהם ישתמש ה Client על מנת לאמת שזו אכן תשובה לבקשה שנשלחה, authorization code.
  • ה Client עכשיו פונה ל Auth. Server בעצמו,
    •  ושולח לו:
      • את ה authorization code שקיבל
      • client_id – זיהוי של ה client (לא של המשתמש), אינו סודי.
      • client_secret – קוד סודי שרק ה client מכיר (אותו הוא קיבל ברישום).
    • בתמורה הוא מקבל אובייקט JSON המכיל:
      • תאריך תפוגה – ה token טוב לזמן מוגבל (באיזור השעה, בד”כ).
      • access_token – איתו הוא יכול לגשת לנתונים.
      • refresh_token – המאפשר לבקש גישה נוספת, במידה וה access_token פג תוקף.
    • הערה: התקן של OAuth לא מציין מה מבנה ה token, אך מקובל להשתמש ב JWT (קיצור של: JSON Web Token), פורמט הכולל 3 חלקים: Claims, Header, וחתימה.

העיקרון מאחורי ה tokens נקרא TOFU (קיצור של Trust On First Use), והוא אומר שבמקום לשלוח את מפתח הזיהוי בכל בקשה – תוך כדי שאנחנו חשופים ל sniffing, נצמצם את החשיפה לתקשורת הראשונה. בפעולה הראשונה אנו סומכים (יותר) על הצד השני, תחת ההנחה שפחות סביר להיות חשופים ל sniffing ברגע ההתקשרות הראשונית. אם ה access token, למשל, נחשף ב sniffing – הפגיעה תהיה מוגבלת לזמן הנתון, ועדיין ה refresh token וה client_secret לא נחשפו והם יכולים להמשיך לנפק בצורה מאובטחת יחסית access_tokens אחרים.

  • בשלב האחרון ה Client ניגש לשירות B בעזרת ה access_token – ושולף ממנו את הנתונים שביקש.
    לכאורה בתרשים זו קריאה בודדת, אך בעצם יכולות להיות עוד קריאות לאורך זמן.

    • אם פג התוקף של ה access token, ה Client לא יורשה לקבל את הנתונים. הוא יצטרך לפנות עם ה refresh_token ל Auth. Server ולקבל access_token ו refresh_token חדשים.

ציינו שיש 4 סוגים שונים של Grant בתקן. הנה תרשים החלטה מקובל שעוזר להחליט באיזה Grant כדאי להשתמש (מבוסס על תרשים של Alex Bilbie):

בקצרה:

  • Authorization Code Grant – הוא ה flow שעברנו עליו. אם המשאב הוא זיהוי של המשתמש (למשל: email), אזי יישמנו סוג של מנגנון Authentication על גבי OAuth.
    • ה Flow מתבסס על המצאות דפדפן והיכולת לבצע Re-direct (כלומר: Multi-page app, לפחות לשלב ה login).
    • ה Client הוא צד-השרת של האפליקציה, בו ניתן לשמור את ה client_secret בצורה מאובטחת.
  • Client Credentials Grant – הוגדר עבור חלקים שונים של אותה האפליקציה (הגדרה: “ה Client עצמו הוא ה Resource Owner”), שיש בין החלקים אמון גבוה. האימות הוא שרת-לשרת, ולא דורש התערבות של המשתמש. זהו בעצם מן גרסה משופרת של Basic Authentication בין שרת לשרת שמיישם את עקרון ה TOFU. מיותר לציין שנעשה שימוש נרחב ב Flow זה גם בין אפליקציות זרות, וזה לא דבר רע בהכרח (יותר טוב מ Basic Auth).
    • Flow זה גם נקרא two-legged OAuth (כי יש בו רק שני שחקנים מעורבים), בניגוד לכל שאר ה flows הנקראים three-legged OAuth.
  • Implicit Grant – הוגדר עבור אפליקציות ווב או מובייל שבהן לא ניתן לסמוך ברמה גבוהה על ה client_secret. לאפליקציית mobile ניתן לעשות reverse engineering ולשלוף את הקוד, בווב – …זה אפילו יותר קל.
    • יש כאן פשרה של אבטחה על מנת לאפשר כן סוג של Delegation סביר של הרשאות.
    • ב Flow הזה אין refresh Token – ולאחר שפג תוקפו של ה access_token יש לבצע Authentication מחדש.
    • לא מעבירים ל Client את ה Auth. Code (כי לא סומכים עליו – הוא לא מספק אבטחה מוגברת), אלא ישר שולחים לו את ה access-token.
  • Password Credentials Grant (נקרא גם Resource Owner Credentials Grant) – הוגדר עבור אפליקציות בעלות Trust גבוה. ב Flow הזה המשתמש מספק את שם המשתמש וההרשאות שלו לאפליקציה (שלא שומרת אותן!), והיא משתמשת בהן על מנת לקבל access_token בשמו. את ה access_token אפשר לשמור בצורה מאובטחת(!) באפליקציה.
    • אם ה access_token נגנב אז אפשר לגשת איתו רק לנתונים מסוימים של משתמש יחיד – נזק מוגבל.
    • את ה access_token יש לחדש מדי פעם, על ידי זיהוי מחדש של המשתמש. באפליקציות מובייל לא מקובל לבקש מהמשתמש סיסמה מחדש יותר מפעם בזמן מה…. חודש, נניח?

באיזה Flow כדאי להשתמש באפליקציית מובייל?

ב Spec המקורי ההגדרה הייתה להשתמש ב Implicit Grant: מעט אמון, ומעט אבטחה.
מאז יש מעבר לשימוש ב Authorization Code Grant, כאשר משתמשים להרשאות ב Native Browser ולא WebView. למשל: SFSafariViewController ולא WKWebView.

האם אפליקציית מובייל יכולה לשמור Client Secret ב Source Code שלה בצורה אמינה? באנדרואיד, למשל, קל מאוד להוריד apk ולבצע לו Reverse Engineering. ההמלצה אם כן היא להחזיק את הקוד ויישום ה OAuth בקוד ++C (קרי שימוש ב NDK) ולא ב Java – שם ה reverse engineering הוא קשה משמעותית.

Stormpath (שנרכשו לאחרונה ע”י OKTA) בכלל לא דנים בשאלה – ושולחים את המתכנתים ליישם Password Grant. אני לא בטוח שלא מעורבים פה שיקולים עסקיים (לספק Flow שקל ללקוחות ליישם, ולא להטריד אותם ב”זוטות”).

התשובה המורכבת יותר היא: זה תלוי ב Use-case: כמה האפליקציה שלכם נפרצת? כמה רגישים הנתונים שאתם ניגשים אליהם בעזרת האפליקציה? רמת האבטחה כאן היא, במידה רבה, בפרטים.

לסיכום:

בתקשורת שרת לשרת

חוזקות:
  • עדיין פשוט ליישום.
  • TOFU עדיף על העברה של המפתח בכל פעם.
חולשות:
  • לא תוכנן במקור לשימוש בין שרתים עם Trust מוגבל.
סה”כ טוב מספיק עבור מגוון שימושים, ועדיף על פני Basic Authentication.

בתקשורת Web 

 
חוזקות:
  • עדיף על Basic Authentication, בכמה מובנים (בעיקר Authorization Code Grant).
  • הפך כמעט לקונצנזוס – יש מעט מאוד אלטרנטיבות לפעולה של Delegated Access / Authorization.
חולשות:
  • לא תוכנן כפרוטוקול Authentication, ולפעמים אנשים מפספסים את זה ורצים איתו ככזה.
  • מימוש יחסית מורכב בצד-השרת (בצד-הלקוח המימוש טריוויאלי)
  • Room For Error: ה Specification שלו מבלבל, ומגוון האפשרויות – מובילים למימושים / יישומים רבים שאינם באמת מאובטחים דיים. מספק “תחושת אבטחה מוגזמת”.

בתקשורת מובייל

 
חוזקות:
  • עדיף על Basic Authentication ?
חולשות:
  • Mobile App נחשבת לעתים קרובות כ Trusted – למרות שזה שיקוף לא נכון של המציאות.
  • חלק ממנגנוני האבטחה של OAuth מסתמכים על המצאות דפדפן שאפשר לסמוך עליו: אין יכולת ל redirect. שימוש ב WebView פותח פתח ל Phishing / Clickjacking.
  • Implicit Grant טוב מ Basic Authentication רק במעט.

OpenID Connect

מעט היסטוריה שתעזור להבין את השתלשלות האירועים:

  • 2006- יצא תקן לאימות זהות בשם OpenID 1.0.  הוא עובד בערך כך: “אני ליאור”, שואלים צד שלישי שסומכים עליו: “האם זה ליאור?”, התשובה היא “זה ליאור” – ואז מאשרים את זהותי.
  • 2007 – יצא OpenID 2.0 עם כמה שיפורים.
  • 2007 – יצא 1.0 OpenID Attribute Exchange (בקיצור OIDAE) – הרחבה של OpenID 2.0 המאפשרת גם למשוך פרטים נוספים על המשתמש “זה ליאור, הוא בן 40, ויש לו 3 ילדים”.
  • 2010 – יצא OAuth 1.0
  • 2012 – יצא OAuth 2.0
  • 2014 – יצא פורטוקול OpenID Connect (בקיצור: OIDC) שמשלב בין OpenID 2.0 + OIDAE על גבי ה Framework של OAuth 2.0 בצירוף של JWT (וחברים).

לא נכון להשוות בין OpenID ל OpenID Connect. זה כמו להשוות בין Ext2 ללינוקס (בהגזמה).
OIDC אינו תואם ל OpenID בגרסאותיו השונות – הוא רק שואב מהם רעיונות.

OIDC הוא פרוטוקול, והוא סוגר הרבה מהפינות הפתוחות של OAuth 2.0:

  • הוא מחייב כללים רבים שהם בגדר המלצה ב OAuth 2.0.
  • הוא מגדיר את מבנה ה tokens (על בסיס JWT) – שב OAuth 2.0 פתוחים לפרשנות.
  • הוא מגדיר scopes סטנדרטיים (email, phone, וכו’) – המאפשרים התנהגות סטנדרטית מסביב למידע בסיסי של המשתמש. הפרוטוקול מגדיר endpoint חדש הנקרא userInfo Endpoint ממנו ניתן לשאוב מידע בסיסי על המשתמש.
  • הוא גם פותח בתקופה בה אפליקציות מובייל הן מאוד משמעותיות, ויש התייחסות רחבה יותר למובייל בהגדרת הפרוטוקול.
  • החל מ 2015 יש הסמכה של OIDC, ויש רשימה של מימושים שהם Certified, אפשר כבר לצפות ל Compatibility.
  • OIDC מגדיר סוג נוסף של token הנקרא ID Token המאפשר ל Client לדעת כמה פרטים על המשתמש ועל מצב ב Authentication שלו. עיוות נפוץ של מימושי OAuth 2.0 הוא לאפשר ל Client לקרוא את ה Access Token – מה שפוגע ב Segregation of duties.
  • הפרוטוקול מוסיף הגנה בפני התקפת replay: עשיתי sniffing לתקשורת ולא הבנתי מה נאמר – אבל אבקש מהשרת לעשות זאת עוד פעם (מה שלעתים יגרום נזק).

הנה ה Flow הבסיסי של OIDC, שהוא בעצם התאמה של ה Flow המקביל שתואר עבור OAuth 2.0:

ה Flow מעט פשוט יותר, לא מתבסס בהכרח על דפדפן, והיעד הוא להשיג מידע על המשתמש – ולא “משאב כללי”.

האם OpenID Connect הוא הטוב מכל העולמות?

אם אתם מעוניינים ב Flow של authentication – אז הוא אופציה מבטיחה. קשה לי לחשוב על מקרה שבו עדיף לעשות Authentication על גבי OAuth 2.0 ולא על גבי OCID.

OIDC הוא פרוטוקול צעיר יחסית, שעדיין לא זוכה לאימוץ דומה לזה של OAuth 2.0. יש אולי עשר מימושים ויותר של OAuth 2.0 על כל מימוש OIDC.בשנים הראשונות, מימושים של OIDC זכו לכמה “פאדיחות”. במימוש של Facebook התגלה באג חמור, שזיכה את המגלה שלו ב Bug Bounty הגדול ביותר בהיסטוריה של פייסבוק. מימוש ה reference של ארגון ה OpenID עצמו סבל מכמה בעיות, וגם מוזילה נכוותה.

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

OpenID מסומן היום כמחליף הטבעי של SAML 2.0 (פרוטוקול אימות זהות / SSO) מסורבל ועם תיעוד לקוי – אבל שמילא את מטרתו במשך תקופה נכבדת.

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

בתחום המובייל (כלומר: native app) פרוטוקול ה OIDC עדיין לא נחשב טוב מספיק. שתי תקנים מרכזיים Proof Of Possession ו PKCE בפיתוח – ואמורים להעלות מדרגה בתחום.

OpenID Connect הוא לא מושלם. למשל: קיימת עדיין הדילמה של החזקת גישה למערכות רבות ע”י Identity Provider אחד. יש סכנה שפריצה למערכת הזו תאפשר גישה לתוכן רב – אך היא ככל הנראה פחותה מהסכנה שבפיזור ססמאות. מבין האופציות הקיימות, OpenID Connect היא האופציה העדיפה.

השוואה מהירה בין SAML 2.0 ל OCID

סיכום

טוב, יכול להיות שפוסט זה הוא לא חומר הקריאה האידאלי בחופשת החג – עם הילדים. יכול להיות…
מצד שני, אם אתם הולכים לבצע תהליך Authentication בווב – כדאי שתכירו את מגוון האפשרויות הקיים והשמעות שלהן. אני לא טוען שיש לממש במערכת “מקסימום אבטחה”, הכל תלוי בהקשר. כנראה שהכי נכון זה לממש “מספיק אבטחה”. כמה זה “מספיק”? – רק אתם תוכלו לומר.

שיהיה בהצלחה!

—-

קישורים רלוונטיים

ה OAuth 2.0 Threat Model המגדיר את הסיכונים השונים ביישום OAuth.
ה OAuth Grants מוסברים על ידי Alex Bilbie.
עוד קישור טוב על OAuth 2.0
“OAuth has ruined everything”
מדריך טוב ל OpenID Connect

התקפת מניעת-שירות, וכיצד האינטרנט בחוף המזרחי – הושבת?

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

DDoS (כלומר: Distributed Denial of Service) היא כבר התקפה שיש מאחוריה סיפור מרגש: אלפי מחשבים (אולי אפילו מיליונים) – תוקפים שירות גדול וחזק: ענק אינטרנט, בנק, תשתית ממשלתי, וכו\’. האם להקת הציפורים, שכל אחת ממנה חסרת חשיבות – יצליחו ביחד להפיל את הענק?
המטאפורה של רבים מול יחיד – היא חומר מצוין לסיפורים \”ויראליים\”, וכך התקפות ה DDoS זוכות לחשיפה רחבה – גם בקרב אנשים לא טכניים שאין להם מושג בסיסי במערכות מחשבים.
סצנה מתוך סרט \”הציפורים\” של היצ\’קוק. מקור: http://www.filminamerica.com/Movies/TheBirds

כיצד נראית התקפת DoS?

להלן דוגמה פשוטה מאוד:

אני מתחבר לאתר ״האכל חתול״ (שעוקב אחר חתולים עזובים ונקודות בהן ניתן למצוא אותם ולהאכיל אותם) ולוחץ על כפתור ה refresh ללא הפסקה. יודעים מה? אני משתמש ב Refresh Monkey, תוסף סטנדרטי לכרום – בכדי שהמחשב יעשה זאת עבורי.
Refresh Monkey. הטאב יבצע refresh חמש פעמים בשנייה – ואני יכול גם לפתוח מאה טאבים כאלו.
בפעולה פשוטה זו הגדלתי, לבדי, את סה\”כ העומס על האתר: נניח שפי 4 – כי זה אתר נישתי עם מעט traffic.
גם אם המערכת לא קורסת, היא לא מוכנה לטפל בכמות כזו של בקשות – והיא תאלץ לדחות חלק מהבקשות.
חלק מהבקשות שיידחו הן שלי, אבל חלק נוסף של משתמשים לגיטימיים – וכך יצרתי נזק: מנעתי ממשתמשים לגיטימיים שירות – Denial of Service.

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

—

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

הדף הראשי של האתר – הוא דף שמתוכנן להיות מהיר. רוב ה traffic מגיע אליו. העבודה שנעשית בו היא שליפה של חתולים באזור נתון. בחולון, העיר בה אני גר יש כמות ממוצעת של חתולים שמוזנים במערכת, אולם אם אדווח על המיקום שלי במרכז ת\”א – צפיפות החתולים המתועדים גדולה פי שלושה!
בכדי לשפר את ההתקפה שלי – עלי לחשוב כיצד אני גורם לשרת לעבוד יותר קשה. אם אוכל לגרום לדף הראשי באתר לעבוד קשה יותר, אולי כך אפגע ביותר משתמשים, נניח 15% מהמשתמשים.

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

מצאתי באתר דף שנקרא: ״פריסה ארצית של חתולים ויחס האכלות״. בינגו! זה כנראה דף שלמערכת הרבה יותר קשה לרנדר (כי הרינדור מבוסס על חיתוכים וסיכומים בבסיס הנתונים). אם הנתונים אינם cached בצורה יעילה (מה שיכול ממש לקלקל!) – אני מסודר.
כמו כן, סביר יותר שדף שולי במערכת זכה לפחות שיפורי ביצועים – פשוט כי התנועה הדלילה אליו פחות משפיעה על סה\”כ ביצועי המערכת.
עבורי  – זו הזדמנות מצויינת! אני אלמד את בוני האתר כמה לא יעיל הקוד מאחורי הדף הזה (!Muahaha). אני משגר עשרות בקשות בשנייה לרינדור הדף, ומייד מנתק את ה connection (ללא RST – מבלי להודיע). לשרת ייקח כמה שניות להבין שנעלמתי – ובזמן הזה הוא עדיין יעבוד להכין את הדף ולנסות לשלוח אותו אלי.

התקפה כזו עשויה להיות הצלחה גדולה: אמנם ״פריסה ארצית של חתולים ויחס האכלות״ – הוא דף שאינו חשוב במערכת, אבל אותם CPU ו Database שמשרתים אותו – משרתים גם את שאר המערכת. ברגע שתפסתי אותם, הצלחתי למנוע שירות מ90% מהמשתמשים הלגיטימיים שמנסים לגשת לאתר הבית, ולהאט משמעותית את זמני התגובה ל 10% המשתמשים שכן הצליחו לקבל שירות. הצלחה גדולה!

מקור: Scudlayer

על DDoS ו SDoS

לאחר שהבנו כיצד התקפת DoS עובדת – מה בעצם המשמעות של DDoS, מונח שהוא כנראה אפילו יותר מוכר?

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

יתרה מכך, מנגנוני ההגנה המקובלים בפני התקפת DoS היא לזהות כמות לא סבירה של traffic ממשתמש יחיד – ואז לחסום אותו ברמה היעילה ביותר (למשל: לדחות בקשות ל tcp connection, הנדרש בכדי לבצע בקשת HTTP, על בסיס כתובת IP של השולח).

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

על מנת לייצר התקפת DDoS יעילה, עלי לאסוף אלפי מחשבים, אולי עשרות אלפים, ואולי יותר – שאולי לשלוט בהם. כל מחשב כזה נקרא Zombie, וצבא של זומבים נקרא גם BotNet. האיסוף מתבצע בד\”כ ע\”י נוזקה שתתוקן במחשב ותהיה במצב רדום – עד אשר ארצה לבצע את ההתקפה. הנוזקה לא צריכה \”להשתלט על המחשב\”: היא רק צריכה להתקין agent שמאזין ל port מסוים ומאזין לפקודות משרת ההפעלה שלי. בעת ההתקפה, בעל המחשב כנראה לא ירגיש בכלל שהוא שותף להתקפה. לא יפריע לו – ולא יהיה לו טריגר לנסות ולהסיר את ה agent שלי.
את הנוזקה אני יכול להפיץ באתרי הורדות קבצים במשך חודשים או שנים – עד לרגע ההפעלה. מי שרוצה לקצר תהליכים ויש ברשותו משאבים – יכול גם לרכוש רשתות BOTNET בשוק העברייני, ממישהו שטרח והקים אותן.

בהתקפה שהתרחשה בימים האחרונים על Dyn – ספקית שירותי DNS (\”ספר הטלפונים של האינטרנט\”) גדולה, השתמשו ברשת Mirai – רשת Botnets מוכרת, שכבר שימשה לכמה התקפות בעבר, אם כי לא בסדר גודל כזה (מקור).

ההתקפה על Dyn. מקור: TechCrunch

מה שהיה חדש יחסית בהתקפה הוא השימוש ב \”מכשירים בסיסיים\” או \”דברים\” (IoT – Internet Of Things) – לביצוע ההתקפה. כלומר: הזומבים ב Mirai Botnet הם טוסטרים, שואבי אבק, מצלמות אבטחה – רכיבים שונים בעלי גישה לאינטרנט. הנוזקה \”Mirai\” סורקת את האינטרנט וברגע שמזהה מכשיר שכזה מנסה להתחבר אליו כ Admin בעזרת רשימה של users/passwords נפוצים שיש ברשותה. אלו הם לרוב ה defaults שמסופקים מהיצרן או שם וססמה קבועים – שלא ניתן בכלל להחליף.

\”למה שאשנה את הססמה של הטוסטר החכם שלי?\” – תוהה לעצמו המשתמש הביתי המתוחכם (שבכלל מודע לאפשרות). \”מה יעשו – ישרפו לי את הצנים בבוקר? חחחח\”.

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

בעוד על DDoS כולם כבר שמעו, על SDoS כמעט ולא שומעים – אין גאווה גדולה לארגון לספר שהותקף בכזו התקפה.

SDoS הם ראשי תיבות של Self Denial of Serive (מושג מקביל: Unintended Denial of Service) בהם ארגון מייצר לעצמו traffic שהוא לא מסוגל לעמוד בו – ואז נאלץ לדחות (= לא לספק שירות), לכמות גדולה של משתמשים לגיטימיים.

דוגמה קלאסית: קמפיין שיווקי שלא תואם (או אולי תואם, ותוצאותיו לא נצפו ע\”י ה R&D/Operations) – שמגדיל את התעבורה פי כמה מונים – אך המערכת לא יכולה לעמוד בכמות ה traffic שנוצר.

פאדיחות.

בהתקפת DoS/DDoS זה מה שאתם רוצים שבעלי האתר יראו: פחות traffic מטופל, וזה שמטופל – הוא איטי ומציק.
מקור התמונה: New Relic

סגנונות תקיפה נפוצים

התקפת DoS לא חייבת להיות ברמה הטכנולוגית. לדוגמה: נניח שאני רוצה לתקוף אפליקציית מוניות, מספיק שאבצע כמה מאות או אלפי הזמנות ואבטל אותן ממש לפני שהנהג מגיע ליעד – בכדי למנוע מנוסעים רבים שירות בזמן הזה. מספיק שאתקשר למסעדה ואבצע 20 הזמנות מפוברקות של שולחנות לאורך הערב – בכדי לפגוע במסעדה. במערכות של בתי קולנוע, בעת ביצוע ההזמנה – נשמרים המקומות שבחרתי למשך 15 דקות גם מבלי שסיפקתי פרטים מזהים או אמצעי תשלום. מספיק שאתחיל הזמנה אחת בכל דקה (ואסמן חמישה מקומות) – בכדי למנוע מ 75 מושבים להתמלא ע\”י לקוחות אמיתיים.

בכל זאת, ניתן לאפיין ברמה הטכנולוגית כמה סגנונות נפוצים לביצוע התקפות DoS/DDoS:

HTTP Flood

התקפות HTTP Flood הן ההתקפות הפשוטות והישירות – כמו הדוגמה שנתתי למעלה.
את ההתקפה אפשר למקד בכמות בקשות גבוהה, או בתפיסת רוחב הפס (\”Bandwidth attack\”) של האתר. את סוג ההתקפה הזו עושים ע\”י הורדה של כמויות גדולות ככל האפשר של נתונים מהאתר (לזומבים, כמו בחשבון ביתי, יש לרוב יש יותר נפח הורדה – ופחות נפח העלאה).

כדי לייצר התקפה מוצלחת חשוב למצוא דפים / אלמנטים באתר שהם איטיים במיוחד, דורשים חישוב רב – והכי חשוב: אינם cached! חשוב למצוא כמה דפים כאלו. במהלך ההתקפה האתר יכול להתגונן ע\”י השבתה מכוונת של דף שאנו תוקפים – ואז נרצה לעבור מהר מאוד לדף איכותי אחר.

האוייב הגדול ביותר שלנו הוא CDN (כלומר: cache יעיל במיוחד). CDN בנוי להגשת תוכן בכמויות גדולות בצורה אופטימלית – ואותו יהיה קשה מאוד להעמיס. תשתית ה CDN מנוהלת ע\”י ספק שמשרת עשרות אלפי אתרים – והקיבולת של ה CDN היא אדירה.

טריק פשוט ומקובל הוא לייצר אלמנט אקראי (למשל: ב query string) ב URL – שיגרום ל CDN לחשוב שאין לו את המשאב – ולהעביר את הבקשה ישירות לאתר.

למשל:

הרכיב \”random=198982\” ב URL כמעט ואף פעם לא יגרום לשרת לדחות את הבקשה (מי מתגונן בצורה כ\”כ הדוקה?) – ובד\”כ יגרום ל CDN לחשוב שמדובר במשאב ייחודי שלא נמצא אצלו ב Cache.

התקפות רזות: SYN Flood ו UDP-Based

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

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

הרעיון של התקפות אלו הוא להימנע מיצירת ה TCP connection, שהיצירה שלו אורכת זמן (גוזלת מהמתקיף משאבים) – ואז יש יעד ברור לתשובה.
להזכיר: TCP Connection הוא הבסיס לביצוע HTTP Request. לא יהיו לנו בקשות HTTP בסגנון ההתקפה הזה.

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

אולי אפילו טוב יותר: הוא לא יענה במשך זמן ממושך (או בכלל) – ואז המערכת אותה תקפנו לא תוכל בכל הזמן הזה לשחרר את המשאבים שהקצתה לצורך ה connection. רוב המערכות יחכו כמה שניות ואז יוותרו על המאמץ לייצר connection, מערכת שלא עושה זאת (אין לה timeout) – היא פשוט טרף קל!

מקור התמונה: Cisco

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

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

אפשר לבצע Ping / Echo ולתת לשרת לענות. אפשר לנסות Pings עם payload גדול – שעשויים להקשות על השרת המרוחק, ואפשר (זה ממש מרושע) לנסות לשקר שכתובת ה IP שלנו היא כתובת של שרת אחר ב cluster של המערכת המותקפת – ואז לתת לשרתים השונים של המערכת לבצע ping בינם לבין עצמם…

בכל המקרים הללו, אנחנו תמיד נשלח הודעות ונשקר לגבי כתובת ה IP שלנו (כלומר: של הזומבי) – כך שיהיה קשה יותר לאתר את מקור ההתקפה ולהתגונן בפניה. זה ייתרון שניתן לנו בכך שאנו לא מייצרים TCP connection.

התקפות Amplification (הגברה)

אם יש בשליטתי 10,000 זומבים, ואני יכול לחבר לכל אחד מהם \”מגבר\” שיאפשר לו לייצר פי 10 traffic – הרי שכללתי במידה רבה את כלי ההתקפה שלי!

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

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

מגברים \”טבעיים\” אחרים שניתן למצוא ברשת האינטרנט כוללים:

  • שרתים שעונים לפרוטוקול SNMP (פרוטוקול ניהול רשת) – היחס בין גודל הבקשה לגודל התשובה יכול להגיע לעד פי 600, יותר! לרוע המזל, אין הרבה שירותי SNMP שפתוחים לאינטרנט הרחב…
  • שירותי NTP (כלומר: Network Time Protocol, הפרוטוקול בעזרתו שרתים מסתנכרנים על השעה הנכונה) – הם יעד פופולארי. פקודת monlist של הפרוטוקול (המחזירה רשימה של 600 השרתים האחרונים שביקשו שירות) היא בעלת יחס החזרה של פי 200.
  • מערכות Peer to Peer – שניתן למצוא פרצה ולבלבל את כל ה Peer שאנו מתקשרים איתם באותו הרגע ולחשוב שהשרת המותקף הוא בעצם אני. הם עלולים לנסות שוב ושוב עד שיקבלו את התשובה שהם מצפים לה…
  • וכו\’
התקפות הגברה נמדדות לרוב בכמות ה Bandwidth שהן מייצרות. השיאים נשברים כל הזמן, והשיא הידוע לי הוא 602 Gbps – כלומר: traffic של 602 ג\’יגהביט בשנייה (או 75 ג\’יגהבייט בשנייה). שיא שבוודאי יישבר.

סיכום

מה הופך התקפות DDoS לכ\”כ פופולאריות?
  • הן פשוטות יחסית ליישום. הרבה יותר פשוטות מהתקפות אחרות. 
  • הן מתאימות כמעט לכל מטרה: הן לא תלויות ב stack טכנולוגי מסוים, או בפגיעויות מסוימות של המערכת.
  • קשה לאתר את התוקף – ובמיוחד בהתקפות שאינן מבוססות על TCP. היכולת להתחמק – היא אינטרס עליון של התוקף.
התקפות DDoS הן חלק מהתרבות הפופולארית – וזוכות לחשיפה תקשורתית מוגברת מצד העיתונות. הן פופולריות כנגד אתרים גדולים, נגד שירותים ממשלתיים, וגם נגד Online Games (שם המשתמשים מתקשים *מאוד* להתנתק מהמשחק האהוב עליהם – אפילו לשעות ספורות). פעמים רבות ישנה התקפה קטנה \”לדוגמה\”, שלאחריה יש דרישת כופר – שתשלום עליה ימנע את ההתקפה \”הגדולה\” (ואז ניתן לעבור ליעד הבא).
כמובן, שאין לי שום קשר להאקינג או תקיפת חתולים (שלא מתנחלים על הגג של האוטו שלי), והמטרה של הפוסט היא לא לעזור לכם לתקוף – אלא לעזור להבין את האיום וכיצד להתגונן בפניו.

כיצד מתגוננים?
  • מעבירים את התעבורה לאתר דרך שירות שיודע לזהות ולסנן traffic של התקפת DDoS (כמו CloudFlare או Akamai) . שירות כזה עולה כסף, אך הוא מסוגל לאתר ולמנוע מכם את רוב ה traffic של התקפת DDoS. 
  • חוסמים לגישה מהאינטרנט כל port או endpoint שאינו הכרחי.
  • בונים את המערכת כך שיהיה ניתן להשבית (disable) בקלות מנגנונים יקרים במשאבים של המערכת. בעת התקפה, עדיף לאבד יכולת או שתיים של המערכת – מאשר את כל המערכת.
שיהיה בהצלחה!

Amazon Virtual Private Cloud

VPC (קיצור של Virtual Private Cloud) היא רשת מבודדת לוגית ב Data Center של AWS. היא באה לדמות Data Center פרטי של ארגון (כלומר: ב On-Premises), בו תעבורת הרשת, והגישה לשרתים מוגבלת למי שנמצא בתוך ה Data Center.

  • מבחינה טכנית, ניתן לחשוב עליה כתת-רשת (subnet) בתוך אמזון שמוקצה רק לכם.
  • מבחינת אבטחה, ניתן לחשוב עליה כ VLAN [א] – רשת משותפת שהתשתית יודעת להפריד בין packets של תתי-רשתות נפרדות – הפרדה מוחלטת.
VPC הוא לא שירות פרימיום. הוא כמעט חינם, ואם אתם פועלים ב AWS ולא משתמשים בו – כדאי להכיר.בניגוד לניהול רשת “קלאסי” בו צריך להכיר את הראטורים השונים ולתכנת אותם, העבודה ב VPC היא ברמת התוכנה ובממשק אחיד של אמזון – סוג של Software Defined Networking (קונספט שגם תופס תאוצה ברשתות On-Premises).

למרות שה VPC מבודד אותנו משאר העולם, ניתן לבצע קשרים מאובטחים עם רשתות אחרות:

  • VPN שיחבר בין רשת אחרת של הארגון (למשל – המשרד) ל VPC בו נמצאים השרתים.
  • VPC Peering – חיבור (שניתן להגדיר את מידת החופש שלו) בין שני VPCs, למשל: VPC של ספק שירות או לקוח, או אולי VPC אחר של הארגון שלכם (כי לעתים נכון ליצור בענן כמה VPCs לאותו הארגון).

אם אתם רוצים אבטחה אפילו גבוהה יותר, אז VPC תומך במצב של הפרדה מוגברת – מה שנקרא “dedicated tenant”.
כל ה EC2 instances שנוצרים בתוך VPC שהוא dedicated tenant הם dedicated instances (כלומר: השרת הפיסי רק משרת אתכם – אין לכם “שכנים”), וגם חלק מתשתיות הרשת יהיו מופרדות בצורה טובה יותר – עבורכם.
השירות הזה, באופן טבעי – מגדיל את העלויות בצורה משמעותית.

מה החשיבות של VPC, ומדוע לא כדאי לעבוד באמזון בלעדיו?

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

אמנם גם ללא VPC ניתן להגן בעזרת “Firewall” על השרתים שלכם: ניתן לאגד שרתים דומים בקבוצה הנקראת “קבוצת אבטחה” (Security Group), ואז להגדיר:

  • תקשורת נכנסת – כתובות IP, פורטים, ופרוטוקולים (tcp, HTTP, וכו’) ספציפיים שיכולים לגשת למשאבים בקבוצת האבטחה.
  • תקשורת יוצאת – כתובות IP, פורטים, ופרוטוקולים אליהם יכולים המשאבים בקבוצת האבטחה לפנות.

הגישה הזו היא מוגבלת:

  • ניתן להגדיר רק הרשאות (whitelist) ולא חסימות (blacklist).
  • אם אתם רוצים לבודד בין קבוצות שרתים שלכם (“ניתן לגשת לבסיסי הנתונים רק מתוך ה Application Servers”) היא הגדרה כמעט בלתי אפשרית ללא VPC: כתובות ה IP משתנות כל הזמן, ויהיה עליכם לעקוב אחר השינוי ולעדכן את ה Security Groups. נתקן: אפשרי – אך לא סימפטי לתחזוקה.
VPC מאפשר הרבה מאוד גמישות להגביל את התעבורה בין כל קבוצת משאבים שלכם – לכל קבוצה אחרת, ובצורה שניתנת לניהול.
עוד צורך חשוב ש VPC פותר הוא בידוד הרמטי יותר בין חלקים במערכת, למשל: משאבים המשרתים מחלקות שונות, בין dev ל production, וכו’. הפתרון שהיה מקובל קודם ל VPC הוא לנהל חשבונות (account) שונים ב Amazon – מה שהקשה מאוד על כמה פעולות אחרות (למשל: העברת נתונים בצורה מאובטחת בין החשבונות).עוד כמה שימושים ל VPC:

  • Compliance – אם יש תקן שמחייב אתכם להגביל ו/או לעשות Audit לכל מי שניגש לקבוצה מסוימת של משאבים – VPC יהפוך את המלאכה לקלה יותר.
  • הפרדה בין dev/test ל production – לצורך הגנה בפני טעויות אנוש.
  • הפרדה דומה בין יחידות שונות בארגון, למשל: ארגון ה BI רוצה אחריות משלו על החשבון, והפרדה מכל מה שמתרחש ב R&D.

“The “Default VPC

החל מ 2014 [ב] כל חשבון חדש שנוצר באמזון, נוצר ב Default VPC – שזו בעצם תשתית התקשורת המשופרת של אמזון שמאפשרת הגדרה של VPCs. אם אתם נמצאים “ב Default VPC” – אין הכוונה שבאמת אתם משתמשים ב VPC, אלא שאתם נמצאים על התשתית החדישה יותר של אמזון, ברשת משותפת… ביחד עם עוד כמה אלפי ארגונים.

תשתית הרשת הישנה יותר של AWS נקראת “EC2 Classic”. היא מוגבלת יותר:

  • לא מאפשרת יצירה של VPC.
  • פחות גמישות ב Security Groups: לא ניתן להגביל outbound traffic, לא ניתן להחליף באופן דינאמי Security Group למשאב).
  • פחות גמישות בהגדרות רשת בסיסיות: לא ניתן לתת למשאב יותר מכתובת IP אחת, קשה יותר לשלוט בהגדרות ה DHCP, DNS, ו NTS של המשאבים.
  • לא ניתן להשתמש ב Enhanced Networking (משלמים יותר, מקבלים רשת יותר “יציבה” ומהירה).
  • וכו’.
אם אתם נמצאים על EC2-Classic – אז כדאי לעבור “Default VPC” גם אם אתם לא מתכננים לנהל VPC משלכם. יבוא היום ואמזון תכריח אתכם לעבור. בכל מקרה, מעבר שכזה הוא תהליך מורכב – אם אתם לא מוכנים לספוג downtime. כלי שיכול להקל בכזה מעבר הוא AWS ClassicLink.

ב Default VPC, כל מכונה חדשה שתוסיפו תקבל אוטומטית כתובת IP ציבורית באינטרנט – בכדי לתאום לאחור להתנהגות של EC2 Classic. זה לא יקרה ב VPC שהוגדר על ידכם.

כמו כן, ב Default VPC כל שרת שלכם יוכל לגשת לאינטרנט – כי הוגדר לו Internet Gateway כברירת מחדל.
ב VPC משלכם, ברירת המחדל היא ששרתים לא יכולים לגשת לאינטרנט – אלא אם חיברתם אותם בעצמכם ל Internet Gateway.
מדוע זה חשוב? כי אם יש לכם שרת שלא אמור מתוקף תפקידו לגשת לאינטרנט (למשל Database Server) – גישה לרשת יכולה לרמז על תוכנה עוינת שרצה על המחשב ושולחת מידע לתוקף. תוכלו למנוע זאת ע”י בקרה ושליטה בתקשורת היוצאת מהרשת שלכם.

יוצאים לדרך!

יצירה של VPC היא פעולה דיי פשוטה, והיא נראית כך:

1. אנו יוצרים את ה VPC ומגדירים לו טווח כתובות (cidr-block) של בטווח הכתובות השמורות לרשתיות פרטיות, בכדי לא להתנגש עם כתובות באינטרנט.

—

CIDR (קיצור של Classless Inter-Domain Routing) היא שיטה להגדרת תתי-רשתות (subnets) שיכולה לנצל את טווח הכתובת של IPv4 בצורה יעילה יותר, ואולי מעט יותר קלה להגדרה מהשיטה של subnet-masks.

התחביר של CIDR נראה כך:

a.b.c.d/x

כאשר כתובת ה IP הבסיסית היא כתובת בת 4 מספרים בני 8 ביט (0-255) – סה”כ 32 ביט, וה Suffix הוא מספר בין 0 ל 32 – המתאר כמה ביטים בכתובת הבסיס הם “קבועים” ומתארים בעצם את טווח תת-הרשת.

למשל:
127.0.0.0/24 – היא צורה לתאר תת-רשת עם טווח הכתובות 127.0.0.0 עד 127.0.0.255.
24 ביט הם שלשה מספרים, ולכן 127.0.0 הוא החלק ה”קבוע” בטווח הכתובת.

עוד דוגמה:
30.0.0.0/8 היא צורה לתאר תת-רשת שטווח הכתובת שלה הוא 30.0.0.0 עד 30.255.255.255.
8 ביט הם מספר אחד, ולכן רק 30 הוא החלק ה”קבוע” בטווח הכתובות.

ניתן להשתמש ב CIDR בכתיבה מקוצרת, ולהשמיט מכתובת הבסיס אפסים שאינם קבועים. למשל הדוגמה הראשונה יכולה להיכתב כ 127.0.0/24 והדוגמה השניה יכולה להיכתב כ 30/8. ניתן למצוא עוד מגוון דוגמאות בערך בוויקיפדיה.

—

בדוגמה שלנו הגדרנו את 10.0.0/16 – הטווח בין 10.0.0.0 ל 10.0.255.255 – טווח אפשרי של 65K כתובות (המקסימום של VPC מאפשר). אנו כמובן משתמשים באחד הטווחים של פרוטוקול ה IP לרשתות פרטיות – לא נרצה התנגשות עם כתובות של שירותים ברחבי האינטרנט. התוצאה של הפעולה מחזירה לנו id של ה VPC שרק נוצר, במקרה שלנו: vpc-a01106c2.

2. בתוך ה VPC עלינו להגדיר subnet לכל Availability Zone. ה VPC, כקונספט לוגי שמכיל הגדרות, יכול להתפרס על גבי Region של אמזון, אבל ה subnet הספציפי יכול לחיות רק ב Availability Zone – שהרי זהו Data Center פיסי.

ה Subnet יהיה בטווח קטן יותר של כתובות IP – כ 256 כתובות, בכדי לא “לשתות” את כל הכתובות של ה VPC, ואנו נייצר אותו ב AZ בסימון a של אירלנד (eu-west1).

3. הנה אנו מגדירים subnet נוסף ב AZ בסימון b, ובאופן דומה. שימו לב שמרחב הכתובות של ה subnet הזה הוא שונה.

התוצאה היא המבנה הבא:

לכל subnet יהיה id, למשל “subnet-d38d91dd” וברגע שנבקש להקים EC2 instance – יהיה עלינו לציין באיזה subnet ליצור אותם.

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

1. אנו יוצרים Internet Gateway, רכיב של AWS שמאפשר גישה לאינטרנט. בהפעלת הפעולה – נקבל id (למשל “igw-c0a643a9”)

2. אנו מוסיפים route ל “router הווירטואלי שלנו”, שאומר שכל כתובת בעולם (0.0.0.0/0), אם לא נמצאה בתוך ה subnet – הולכת ל internet gateway שלנו.

ה VPC מחזיק טבלת ניתוב (routing table) לכל ה subnets, אך ניתן להגדיר טבלאות ניתוב שונות – ולקשר כל subnet לטבלת ניתוב שונה.

“למה שארצה להגדיר טבלאות ניתוב, פחחחח?” – יכול מישהו לשאול.
ברור שזו התעסקות נוספת, קצת יותר low level מרוב העבודה עם אמזון. הדרך לאבטחה טובה, היא לתכנן ולשלוט בניתובי הרשת.

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

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

אז איך מתכננים VPC?

“VPC ניתן להגדיר ב-2 אופנים: VPC יחיד, או ריבוי VPCs – אך יש אלפי תצורות שונות בהן ניתן להגדיר את שני האופנים” — יועץ AWS זקן וחכם.

בתור התחלה, בואו נחלק את המשאבים שלנו באמזון לכמה מחלקות ארגוניות שונות:

  • VPCs בניהול ה R&D:
    • Production
    • Dev/Test – ההפרדה נעשתה כדי למצמצם טעויות אנוש שישפיעו על production.
      יש גם ארגונים שלא מאפשרים למפתחים בכלל לגשת ל production – וזו דרך פשוטה לנהל זאת.
  • VPC עבור ה IT:
    • מערכות ה Active Directory, מערכת ניהול הכספים, נוכחות משתמשים ומערכת ה HR – לא צריכות להשפיע על production, ואף מפתח לא זקוק לגישה אליהן. לכולם יותר נוח שרק לאנשי ה-IT תהיה גישה לרשת זו.
  • VPC עבור ה Data Science
    • צוות ה Data Science זקוק להרשאות Admin ל AWS כי הם מרימים ומורידים מכונות (למשל EMR) בכמויות סיטונאיות, וחס וחלילה לא נרצה שיפגעו בפרודקשיין. “אופס סגרתי לכם 100 מכונות בפרודקשיין, לא שמתי לב בגלל המספר הקטן” – הוא לא מה שאתם רוצים לשמוע…

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

כמו כן, ברוב הפעמים המערכת שלנו תהיה מפוזרת בכמה Regions של אמזון. לצורך הפוסט אני מפשט את התמונה ומניח שאנו פעילים רק ב Region יחיד – ה Region (העתידי) של IL-Center-1 😉 .

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

  1. בתוך ה VPC, יש לנו 2 (בד”כ 3 או 4 – לא היה לי כח לצייר) AZs זהים. בגלל שכל AZ הוא Data Center מבודד פיסית (ואנו רוצים את היתירות הזו) – יהיה עלינו להרכיב subnets סימטרים ב AZs השונים, שיבדלו ע”י טווח כתובות שונה (כלומר: ה CIDR שלהם). כמובן שעדיף לעשות זאת בעזרת כלים אוטומטיים (למשל: Cloud Formation) ולא בצורה ידנית.
    לצורך פשוט התרשים, פירטתי רק את המבנה של AZ סימן a – אנא הניחו ש AZ סימן b הוא סימטרי לחלוטין, גם בתוכן וגם בחיבוריות פנימה והחוצה.
  2. ה Traffic שמגיע מבחוץ (משתמשים באינרטנט, למשל) עובר דרך ה DNS של אמזון (קרי: route 53). ה DNS מספק Load Balancing ראשוני בין ה AZs השונים. משם ה Traffic עובר ל Router של אמזון שמנתב אותו כל פעם ל AZ שנבחר.
  3. הכניסה הראשונית היא ל subnet “ציבורי” אליו ניתן לגשת מכל מקום באינטרנט, ושם אנו מבצעים את הסינון הראשוני של התעבורה. אמזון מספקת לנו שירות, המגיע כ AMI שעלינו להתקין, שנקרא VPN NAT Gateway – שהוא בעצם Reverse Proxy. רוב הסיכויים שנרצה סינון קצת יותר רציני של Traffic, למשל – WAF (קיצור של Web Application Firewall). לאמזון יש גם שירות שכזה – אך הוא עדיין מאוד בסיסי.
    1. אם הרעיון של ה public subnet מזכיר לכם DMZ ברשתות On-Premises זה לא במקרה – זה בדיוק אותו התפקיד, ואותו הרעיון של Layered Security.
  4. ה Subnets הפנימיים (נקראים “פרטיים” כי אנו מגבילים את הגישה אליהם) מכילים את חלקי המערכת שלנו. למשל, ה Subnet הראשון אליו מגיעים מכיל את ה Web Server ואנו יוצרים כלל שמאפשר רק לתקשורת שמקורה ב public subnet – להגיע ל subnet הזה.
    1. באופן דומה, שירות X יסכים לקבל תקשורת רק מה Web Server או כל Subnet שנגדיר לו.
    2. הגדרת הכללים היא קלה: אנו יודעים מה ה CIDR (טווח הכתובות הקבוע) של כל subnet, כך שב Security Group של שירות X אנו נאפשר את ה Subnets (אחד לכל AZs) של ה Web Servers.
      אם מתווספים שרתי ווב חדשים – הם עדיין יהיו בטווח הכתובות של ה subnets, ולכן הכללים שהגדרנו – עדיין יהיו תקפים.
    3. אנו יודעים איזה חלק של המערכת אמור לתקשר עם איזה חלק אחר – וכך אנו חוצצים את השירותים שלנו למספר subnets, ע”פ פרופיל התקשורת שלהם: הנכנסת והיוצאת.
      יש ארגונים שיחלקו את הרשת שלהם ל 3-4 פרופילים שכאלו, ויש כאלו שיחלקו ל 50. הכל תלוי במידת האבטחה שאתם רוצים להשיג ועד כמה אתה מוכנים לטרוח בכדי להשיג אותה.
  5. כפי שציינתי, גם התקשורת היוצאת היא פרופיל שכדאי לשלוט בו. יהיו מעט התקפות יעילות על הרשת שלכם – שלא יידרשו סוג של קשר עם המתקיף.
    1. באופן דומה, נהוג גם את התקשורת היוצאת לסנן בעזרת IDS, WAF, או לפחות NAT פשוט. לאחר הסינון התקשורת תגיע ל Internet Gateway שזה שירות של אמזון (highly available, fully elastic) – שמאפשר את תקשורת הנתונים החוצה.
  6. סביר שתרצו לאפשר גם לעובדים במשרד לגשת לחלקים מהמערכת, ולכך יש שירותי VPN. אם אתם רוצים לאפשר גישה מה VPN ל Web Server, יהיה עליכם להגדיר כלל נוסף שמאפשר ל subnet של ה Web Server לקבל תקשורת מה VPC Gateway.
  7. הזכרנו שהמוטיבציה העיקרית ל VPC היא אבטחה. עוד שירות חשוב של אמזון הוא ה VPC Flow Logs.
    זהו שירות המאפשר לקבל לוגים על כל התעבורה אל ומחוץ ל VPC.
    ישנם שירותי צד-שלישי (כמו Observe Networks, Dome9, SumoLogic, ועוד) שישמחו לאסוף עבורכם את הלוגים הללו, לנתח אותם, להציג ב Dashboard יפה – ואף לנסות ולאתר אנומליות.

עוד כמה פרטים אחרונים

VPN

ניתן לאפשר ערוץ תעבורה בין המשרד, או כל רשת אחרת ל VPC שלכם על גבי VPN. הרכיב באמזון שמאפשר זאת הוא ה VPN Gateway (בקיצור: VGW, נקרא גם Virtual Private Gateway) היודע לעבוד עם פרוטוקול IPSec VPN.

כל חיבור VPN כולל 2 IPSec Tunnels (ערוצים מוצפנים), כך שאם ערוץ אחד כשל, פרוטוקול ה BGP (קיצור של Border Gateway Protocol) ינתב את התעבורה דרך הערוץ השני. ניתן כמובן להגדיר יותר מ VPN Gateway  – וכך לאפשר יתירות של ארבעה Tunnels ויותר.

AWS Direct Connect

AWS Direct Connect הוא שירות של אמזון לחיבור רשת משופר (קווים שאמזון שוכרת לצורך זה, ככל הנראה) בין VPCs ב Regions שונים לרשת של הארגון שלכם. אם יש יש לכם תעבורה משמעותית בין הרשתות – השירות הזה עשוי להפחית עלויות, לשפר latency ולשפר את האבטחה.

התקשורת ב AWS Direct Connect מבודדת ע”י פרוטוקול VLAN – כך שהיא לא תערבב עם תקשורת של VPCs אחרים.

גם בשימוש ב Direct Connect, ניתן להגדיר Tunnels של VPN כ fallback, במידה וה Direct Connect כושל (בעזרת פרוטוקול BGP).

VPC Peering

זוהי היכולת המאפשרת לחבר בין שני VPCs, בהסכמה הדדית, ובצורה קלה ויעילה. את התעבורה שמגיעה מ VPC אחר ניתן עדיין להעביר דרך Firewall או WAF – במידת הצורך.
ניתן בפועל להשתמש גם ב VPN על מנת לתקשר בין 2 VPCs, אם כי VPC Peering עושה זאת בצורה פשוטה הרבה יותר – ובטוחה באותה המידה.

VPC Endpoint

מאפשר להגדיר ערוץ תקשורת פרטי בין ה VPC לשירות של אמזון (ולא דרך הרשת הכללית של ה Data Center).
כרגע השירות היחידי שתומך ביכולת זו הוא S3 – אך עוד שירותים יתווספו בעתיד.

בכדי להשלים את התמונה, ב S3 Bucket ניתן להגדיר (בעזרת Policy) שיסכים לקבל קריאות רק מתוך VPC endpoint מסוים (ע”פ id) – וכך גם לוודא שלא בטעות פניתם ל Bucket שלא דרך הערוץ המאובטח.

סיכום

Virtual Private Cloud היא במידה מסוימת יכולת “לא סקסית” של AWS – אך חשובה מאוד.
לפני כמה שנים דובר כמה ארגונים חוששים, משיקולי אבטחה, לעבור לענן. ראיתי תצורות רשת של כמה חברות גדולות. רובן היו פרימיטיביות יותר ממה שניתן להשיג בעזרת VPC במאמץ סביר. למשל: לחלק כל שירות ל subnet ולהגביל את סוג התקשורת הנכנסת + היוצאת? מבחינת אבטחה – זה נהדר!  בד”כ ארגונים מספקים רמת שליטה שכזו רק על כל ה Data Center או רק בסיסי הנתונים (כולם, כמקשה אחת).

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

שיהיה בהצלחה!

—

קישורים רלוונטיים

AWS re:Invent 2015 | (ARC403) From One to Many: Evolving VPC Design

SDD422) Amazon VPC Deep Dive)

25 טיפים להגדרת VPC

—

[א] מהו VLAN – אפשר לקרוא הסבר קצר בפוסט שפירסמתי על OpenStack.

[ב] 4 בדצמבר 2013, לדקדקנים שביננו.

מבוא לאבטחת מידע (“סייבר” ושטויות שכאלו) – חלק ב’

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

לא עניתי אבל על השאלה המתבקשת: “מה עושים?” כיצד מתגוננים ו/או מתכננים מערכות תוכנה מאובטחות יותר[א]?

– על שאלות אלו אנסה לענות בפוסט הנוכחי.

מודל ה-CIA

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

  • Confidentiality (סודיות) – מניעת חשיפה לא מורשית של מידע.
    • אבני יסוד בהגנה: Authentication (אימות זהות), Authorization (ניהול הרשאות), והצפנה.
  • Integrity (שלמות הנתונים) – מניעת שינוי לא רצוי של נתונים, זיוף נתונים, או השחתת נתונים. הידיעה שנתונים שמשתמשים ניגשים אליהם הם אותנטיים ולא שונו ע”י גורם עויין.
    • אבני יסוד בהגנה: חתימה דיגיטלית, Authentication, ו Audit (רישום הגישות לנתונים)
  • Availability (זמינות) – ווידוא שניתן לגשת לנתונים בכל זמן.
    • אבני יסוד בהגנה: יתירות, וגיבויים / Disaster Recovery.
לשם המודל אין קשר לארגון הביון המרכזי, אולי מלבד מהכוונה לגרום לשם להיות קליט יותר.
המודל עוזר לנו לחשוב על האלמנטים שיש לאבטח על מנת לספק “אבטחת נתונים”, ורק שילוב של שלושתם – באמת מספק אבטחה
.
למשל: נניח שיש גורם שמצפין את המידע שלי בהצפנה כפולה: ה Confidentiality בשמיים – לא ניתן לגשת למידע. אבל אם גם אני לא מסוגל לגשת למידע, כי אין לי את המפתח להצפנה (Availability) – אז מה הטעם?!זה בדיוק מה שתוכנות ransomware עושות – והן פוגעות באבטחת המידע שלנו, אפילו שהן “רק מצפינות אותו עוד יותר” (כי לנו אין את מפתח ההצפנה, ויהיה עלינו לשלם כופר על מנת לקבל אותו).

4 עקרונות יסוד נוספים

מודל ה CIA הוא שימושי – אך כנראה הוא המודל הבסיסי ביותר שניתן לחשוב עליו. להלן קבוצה של עקרונות יסוד חשובים שליקטתי. העקרונות הללו הם ה Design Principles היסודיים, בחשיבה על תכנון מערכת כמערכת מאובטחת.

Non-Repudiation (אי-התכחשות)

בכל גישה למשאב ו/או ביצוע פעולה, חשוב מאוד שיהיה ברור מי האדם שביצע את הפעולה.
הידע מי ביצע את הפעולה מאפשר לנו להגביל פעולות מסוימות (Access Control => Confidentiality), יכולת ניטור הפעולות (Monitoring => Anomaly Detection) ויכולת לבוא “בחשבון” עם מי שביצע פעולה לא ראויה (Forensics => התרעה).
את אי-ההתכחשות משיגים ע”י:
  • Authentication (אימות זהות) – ארחיב עליה בהמשך.
  • Audit או לוגים – רישום מה קרה ומי עשה את זה ומתי.
דרכים מצוינות “למסמס” אי-התכחשות הן:
  • לחלק את אותו username והססמה לקבוצת אנשים – ואז לא ניתן לדעת מי מהם ביצע את הפעולה, או האם הקבוצה בעצם התרחבה ללא “כוונת המשורר”.
  • להשתמש במערכת ב”משתמשים טכניים” (technical users) להם יש הרשאות עדיפות ואיתם מבצעים את הפעולות הרגישות – תוך כדי שממסכים מי המשתמש האמיתי שיזם את הפעולה.
    • דוגמה: הפקודה “sudo bash” בלינוקס.
    • דוגמה נוספת: משתמש הפעיל חישוב של דו”ח / תהליך במערכת, והמערכת מעבירה SQL Query למשתמש טכני (שלו יש גישה מלאה לבסיס הנתונים – כי למשתמש לא נתן כזו גישה! חס ושלום). כשנגלה שמשהו לא טוב קרה בבסיס הנתונים ע”י המשתמש הטכני – לא נדע לקשר זאת לגורם אנושי.
כמה מלים על ססמאות כאמצעי אימות-זיהוי (Authentication)
לכאורה הדרך הקלאסית לזהות משתמש הוא לבקש ממנו שם משתמש וססמה. מן צירוף שרק המשתמש יודע, ואם מישהו הקליד אותו – זהו בוודאי המשתמש!
אבל:
  • לבני האדם יש דברים חשובים יותר בחיים משינון ססמאות מורכבות. רובנו “נופלים” לאותן ססמאות חוזרות (12345, password, querty, וכו’) – מה שמקל על תוקף פוטנציאלי “לנחש” את הססמה שלנו. בעזרת “מילון” / סטטיסטיקה של הססמאות הנפוצות ביותר, ואולי ע”י כמה פרטי רקע שניתן למצוא עלינו ברשת. פעמים רבות יהיה ניתן “למצוא” את הססמה שלנו גם בלי להכיר אותנו באופן אישי.
    מכירים את המסכים עליהם מודבק פתק PostIt עם הססמה למערכת?
  • בעזרת תוכנת מחשב פשוטה ניתן לנסות ולנחש את הססמה שלנו ב Brute force: פשוט לנסות שוב ושוב עוד קומבינציות. אולי מילון של 8000 ססמאות נפוצות (יש כאלו לשפות דיבור שונות), ואולי לנסות את כל האפשרויות לאורך זמן. עדיין קיימות מערכות רבות שלא ינסו לחסום את המשתמש, גם כאשר הוא מנסה להיכנס למערכת עם אלפי ססמאות שונות בכל שעה, ובמשך ימים רבים.
    • ה Password Strength Meter של My1Login יעריך את חוזק הססמה כנגד Brute Force וייתן כמה טיפים. למשל: מדוע הססמה “MyPasswordIsStrong” היא חלשה למדי.
  • חלק מהחלשות שלנו כבני אנוש הן חולשות חברתיות, אותן תוקפים יודעים לנצל – מה שנקרא Social Engineering.
    • אם מישהו ממש נחמד יבקש מכם עזרה – לא תעזרו לו?
    • נניח שלא. אם הוא יעשה משהו טוב עבורכם ואז יבקש עזרה בחזרה – לא סביר יותר שתעזרו לו בחזרה? לא תתנו לו “רק לדקה” את הגישה שלכם למערכת כדי לעזור לו “במצוקה”?
    • יש סיפור על בחור אירופאי שחדר ל CIA אי שם בשנות ה-90 עם אפס אמצעים. הוא ראה בספר הטלפונים את מרחב מספרי הטלפונים של ה CIA (כולם מתחילים ב….) והתקשר באופן אקראי למשתמשים. הוא הציג את עצמו כאיש IT ואמר שהוא ממש מתנצל, אבל בשל בעיה הוא חייב לנתק אותם לכמה שעות מהמערכת.
      “אבל זה לא אפשרי! אני חייב לעבוד!” – רטן עובד ה CIA האקראי בצד השני.
      “אתה יודע מה…” גילה אמפתיה חברית איש ה-IT מדומה “תן לי את הססמה שלך ואני אסדר לך משהו. אבל אל תגלה לאף אחד!”. כמה עובדים נידבו את שם המשתמש והססמה שלהם לקול בטלפון (שבכלל מקורו באירופה) – הכל מרצון טוב להמשיך לעבוד ולא להתבטל…
      התוקף, חדר למערכת, כמשתמש לגיטימי – מתחת לרדאר של כל אמצעי ההגנה (שהיו מקובלים אז).
מה אפשר לעשות?
עולם האבטחה נוטה לחלק את סגנונות אימות זהות המשתמש לשלושה Authentication Factors:
  • Something you Know – כמו ססמה או שם חיית המחמד הראשונה שלכם.
  • Something you Have – למשל כרטיס עובד, קוד שנשלח למכשיר הטלפון (הטלפון = something you have), או Certificate שמותקן על המחשב האישי (עדיף נייד).
  • Something you Are – למשל מדדים ביומטריים כמו: טביעת אצבע, חתימה, קול, צילום רשתית (זה כבר לא מדע בדיוני), צורת הליכה (שמסתבר שהיא דיי ייחודית – כמו טביעת אצבע), וכו’.
דרך אחת לחזק את יכולת האימות היא לחזק Factor ספציפי: לתת ססמה ארוכה, או לשאול אודות שם הילדה שישבה אתכם לשולחן בכיתה ג’. חיזוק שכזה הוא לעתים מתיש, וגורם למשתמשים “למאוס” בשיטה ולנסות לחפש קיצורים – מה שבד”כ לא טוב לרמת האבטחה.דרך מקובלת יותר היא לבצע Multi-Factor Authentication (בקיצור: MFA), כלומר לאמת את המשתמש ע”פ 2 Factors שונים של אימות זהות: ססמה וגם קוד שנשלח לטלפון. השילוב הזה (נניח לגישה מהבית / בעשות לא אופייניות) הוא לא מטריד כ”כ, אך הוא מקשה מאוד על תוקף פוטנציאלי להתחזות אליכם.
דוגמה נפוצה אחרת ל MFA הן מכשיר כספומט שדורש גם כרטיס אשראי וגם קוד PIN.

MFA הוא סוג של Defense-In-Depth – עקרון שעליו נדבר בהמשך.

Implicit Deny (בסלנג: “נופל סגור”)

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

  • כי לא לאפשר גישה – אומר שלא ניתן לגנוב מידע.
  • כי אם נרשה גישה גם במצבי קצה – האקרים יכולים ללמוד עליהם ואז דרכם נעשית קלה יותר: עליהם “להביא” את עצמם למצב קצה – ואז הם “בפנים”.
כשעבדתי בחברת סאפ – זו הייתה הפרקטיקה המקובלת. סאפ היא חברה לתוכנה עסקית – ואבטחת מידע הייתה ערך חשוב בחברה.
כשעבדתי בחברת אימפרבה, חברה של מוצר אבטחה (WAF לסוגיו. אסביר מה זה WAF בהמשך) – דווקא נקטנו בגישה של “נופל פתוח”.למה? האם חברת אימפרבה דאגה פחות לאבטחה?
התשובה היא כזו: סאפ היא זו שכתבה את המוצר, ידעה מה באמת הצרכים העסקיים, ויכלה לשנות אותו ע”פ הצורך כך שגם כאשר יש Implicit Deny – המשתמשים לא נפגעים יותר מדי.
המוצר של אימפרבה הוא מוצר חיצוני, שיש לו מעט מאוד מידע על הנעשה במערכת וכיצד נכון להשתמש בה. אם בכל פעם שיש ספק היינו חוסמים את המשתמש – סביר שהרבה משתמשים היו נחסמים הרבה פעמים, ומביעים תסכול שיגרום מן הסתם ל”הרגעת” מערכת האבטחה הסוררת. זה לא מקום שחברת אבטחה יכולה להרשות לעצמה להגיע אליו.

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

Defense In Depth (הגנה לעומק)

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

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

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

  • קיר בטון חלק בגובה 4 מ’ – הקשה מאוד לטיפוס.
  • שדה של ברזנטים מחודדים (spike mats, נקרא “הדשא של סטאלין”) שמקשה מאוד על ריצה והופך נפילה למסוכנת.
  • גדר חשמלית.
  • מחסומי טנקים – שנועדו לחסום מעבר של רכבים.
  • 302 מגדלי שמירה עם שומרים חמושים שלא יהססו לירות בדמות לא ברורה.
  • פטרול של שומרים מלווים בכלבי תקיפה + שביל גישוש (שביל עם חול מיושר) ברוחב 6 עד 15 מ’ שאדם שיעבור דרכו ישאיר עקבות – וכך ידעו על הימצאותו.
    • שביל הגישוש הוא יתיר לגדר החשמלית – לזיהוי חדירה של גורם לא מורשה למרחב.
  • מרחב גדול שהושטח על מנת להסיר מקומות מחבוא אפשריים – בו דמות שעוברת תהיה בולטת. נקרא “רצועת המוות”.
  • תעלה למניעת מעבר כלי רכב.
    • זוהי הגנה יתירה למחסומי הטנקים, שהזכרנו קודם לכן.
  • קיר בטון חלק בגובה 4 מטר עם גדר תיל בראשו – החומה שגבלה עם גרמניה המערבית.
לעבור את חומר ברלין היה קשה מאוד – זה היה מנגנון הגנה אפקטיבי. רוב הנמלטים דרך חומת ברלין – היו בכלל שומרים שהוצבו בחומה.
האם לא היו בריחות ממזרח גרמניה למערב? היו. הם פשוט מאוד התבצעו במקומות אחרים ולא בברלין. זה מלמד אותנו עוד עיקרון חשוב באבטחה – חוזק האבטחה הוא כחוזק החוליה החלשה ובהחלט לא כחוזק החוליה החזקה במערכת. תוקפים אינטלגנטים תמיד ינסו לנצל את הנסיבות והאפשריות הקיימות – כנגדכם.
עוד חומה מפורסמת ש”פספסה” את העיקרון היא החומה הסינית (המרשימה!!) שמשתרעת למערב סין ואכן עצרה התקפות ממערב, אך לא עצרה את פלישת המונגולים לסין – מהצפון. (בוודאי אתם מכירים עוד דוגמאות היסטוריות דומות…).
בעולם התוכנה, Defense In Depth נראה יותר כמו התרשים הבא: ריבוי כלים ותהליכים, עם מידה מסוימת יש יתירות ביניהם (redundancy) – כך שכישלון של כל רכיב במערכת, לא יותיר את המערכת חשופה:
Layered Security (נקרא גם “Castle Approach”)

האם אתם יודעים כיצד נראו טירות בימי-הביניים?
אם אתם חובבי היסטוריה ולחימה – בוודאי שאתם יודעים!

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

למשל:

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

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

דוגמה מהעולם האמיתי

באופן דומה למדי, אנו מתכננים את ה Data Center המודרני. (הערה: אני מתייחס ל Data Center בענן, בו לא צריך לערבב את הנושא של תחנות-קצה של העובדים כמו ב On-Premises):

האינטרנט

מחוץ ל Data Center שורר האינטרנט – מלא באיומים ופורעי חוק.

כדרך קבע bots עוינים (יש גם bots ידידותיים. למשל: מנוע חיפוש, או כל אלו שעשיו מפתחים לפייסבוק) שפועלים באינטרנט ומנסים לגשת ל Data Center שלנו:
  • הם סורקים את ה ports שפתוחים לאינטרנט, ומנסים לזהות פגיעויות ידועות (באגים, קונפיגורציה לא מספיקה, וכו’).
  • מנסים להפיץ תולעים, סוסים טרויאנים, או Malware (נוזקות) מסוגים שונים ומשונים.
  • אוספים מידע על המערכת שלנו ואופי השימוש בה. מידע שיוכל לשמש כיתרון עבור התוקף האינטליגנטי.
מכאן אנו משתמשים (לצורך הדוגמה – בפועל זה משתנה ממערכת למערכת) ב3 שכבות של רשת: DMZ, רשת אמצעית, ורשת פנימית. בכניסה לכל רשת יש “שער” זהו רכיב הגנה בסיסי בשם Firewall.ה Firewall בוחן את כל ההודעות ברמת ה (Internet Protocol (IP (+ התייחסות ל port של tcp) ומסנן תעבורה שמזוהה כעוינת ע”פ חוקים שהוגדרו לו. למשל:

  • חסימת הודעות משובשות / שלא עומדות בתקן הפרוטוקול (ניסיונות לאתגר את אמינות המערכת שלנו).
  • חסימת הודעות שמקורן ב ip address של תוקף / לא בטוח. או שאנו מגדירים את הכתובות הללו בעצמנו על פי ניסיון עבר, או שאנו מנויים לשירות חיצוני שעוקב ומעדכן אותנו על כתובות כאלו.
  • חסימת תעבורה שמיישמת התקפות נפוצות: למשל – לשלוח הודעה שבה כתובת השלוח היא הכתובת שלנו, כך שננסה לענות לעצמנו (וכך נעמיס את עצמו סתם).
ה DMZ (קיצור של demilitarized zone = “איזור מפורז”)
ה DMZ הוא שכבת הגנה ראשונה שמסננת את ה Traffic מהאינטרנט. ב Data Center בענן, יהיו ב DMZ מעט מאוד שרתים – שתפקידם הוא בעיקר בקרה והגנה (ומכאן השם).
ה DMZ נוגע ב 2 Firewalls:
  • אחד שמחבר את ה DMZ לאינטרנט – וכולל חוקי הגנה גנריים ובסיסיים (כפי שציינתי למעלה)
  • אחד שמחבר את ה DMZ לרשת הפנימית יותר, ומאפשר רק תעבורה מתוך השרתים שלנו – כאלו שסיננו את התעבורה בצורה מקיפה יותר ואישרו אותה.
על אילו שרתים מדובר:
Reverse Proxy – שרת שמעביר תקשורת פנימה ובחזרה (התשובות של השרתים שלנו), אך מסתיר את הכתובות האמיתיות של השרתים הפנימיים (Network Address Translation). מדוע להסתיר את מבנה הרשת הפנימית שלנו? כדי להקשות על תוקף לנהל התקפה. למשל: תוקף החדיר Malware לשרת הפנימית אך הוא לא יודע מה לפקוד עליו כי הוא לא מכיר את השמות האמיתיים של השרתים.
זה התפקיד הראשון של ה Reverse Proxy אבל התפקיד החשוב שלו הוא להיות איתן.
איתן? כן. שרתי האינטרנט שלנו (nginx ,tomcat, וכו’) הם מורכבים, ולא תמיד מתוחזקים ו/או מקונפגים בחשיבה על Security. לא תמיד מעודכנים בעדכוני האבטחה האחרונים. התוצאה – יש בהם הרבה פגיעויות, שחלק מהן אולי מוכרות לתוקפים.
ה Reverse Proxy הוא שרת פשוט למדי שמתוחזק בחשיבה על Security ומעצם כך כמות הפגיעויות שלו נמוכה משמעותית. יש לעדכן אותו ואת מערכת ההפעלה עליו הוא רץ בצורה תדירה.
אנו מעדיפים שה Traffic העוין מהאינטרנט קודם כל ייתקל בשרת מעודכן שכזה – ועליו וינסה עליו את “הטריקים שלו” ( – ולא יצליח) מאשר שייתקל בתוכנה שלנו שאותה יותר קשה להחזיק עמידה ומעודכנת.
Web Application Firewall (בקיצור WAF) – היא הגרסה המודרנית יותר של Reverse Proxy, שכוללת גם את סט היכולות הקלאסי של Reverse Proxy. בדומה ל Firewall, ש”מבין” תעבורה של פרוטוקול IP (פרוטוקול האינטרנט) ויודע לסנן ע”פ חוקים תעבורה בעייתית, ה WAF “מבין” HTTP ויודע לסנן תעבורה בעייתית: תעבורה שמנסה להגיע ל URLs לא תקינים, שמנסה לסרוק רנדומלית URLs עם HTTP Method חשוד (למשל: קריאה ל DELETE על כל ה URLs הידועים של המערכת).
התעבורה הנ”ל יכולה להיות תקינה לחלוטין מבחינת ה Firewall (פרוטוקול IP), אך דיי ברור שהיא עוינת ברגע שמתבוננים בה ברמת ה HTTP. על מנת “לסנן” HTTP יש “להרכיב” את ה packets של IP לכדי הודעת HTTP request, מה שנעדיף לעשות על תוכן שכבר עבר סינון ראשוני של Firewall.
הערה: עבור מערכות שאינן בענן (on-premises) תפקיד ה DMZ הוא מעט שונה (למשל: מכיל שרתי אינטרנט ציבוריים), לא אכנס להבדלים אלו ברמת הפוסט.
רשת אמצעית

ברשת הפנימית הראשונית – אנו מציבים את שרתי הווב שלנו. אלו שמתקשרים עם המשתמשים (דרך ווב או דרך APIs). התעבורה שמגיעה עליהם עברה כבר סינון של ה Firewall החיצוני וה Reverse Proxy (או WAF), וה Firewall שבכניסה לרשת מאפשר רק לתעבורה כזו להיכנס (ע”י חסימת כל כתובות ה IP מלבד אלו של ה Reverse Proxy / WAF).ברשת הפנימית נמצא באופן טיפוסי את הרכיבים הבאים:

Proxy – פרוקסי הוא שרת אינטרנט שמאפשר גישה החוצה אל האינטרנט. עצם הצורך בגישה הוא עסקי ולא דווקא נוגע לאבטחה. בנוסף, ה Proxy לרוב מבצע Caching לתוכן HTTP שניגשים אליו הרבה – וכך משפר את הביצועים של הרשת.
היבט האבטחה של ה Proxy הוא שניתן להגדיר עליו כללים: להיכן אסור לצאת / לשלוח הודעות. ההגדרות יכולות להיות הן ברמת ה IP (כתובת IP) או ברמת ה HTTP (כלומר: URL Pattern).
כאשר יש תוקף שהצליח לגשת לרשת הפנימית שלנו, הוא יצטרך הרבה פעמים לגשת חזרה לאינטרנט. או על מנת לקבל הוראות נוספות לגבי התקיפה, או בכדי לשלוח את המידע שנגנב – חזרה לתוקף. אם נצליח לחסום כתובות IP בעייתיות – אזי נוכל להקשות על התוקפים ולעתים אף לסכל את ההתקפות שלהם.
ה Proxy הקלאסי הוא רכיב דיי בסיסי עם רשימת Deny סטטאטית שיש לנהל בצורה ידנית.
Identity Detection / Prevention System (בקיצור IDS/IPS)
רכיבים אלו מאזינים לתעבורת הרשת לרשת הפנימית (זו שעברה סינון ראשוני ע”פ חוקי Firewall / WAF) ולזהות דפוסים חריגים או כאלו שנראים כמו התקפה פוטנציאלית. ההבדל המהותי בין IDS ל IPS הוא ש IDS, ברגע שזיהה משהו שנראה לו כמו התקפה יעלה Alert – לאנשי ה DevOps / Security. ה IPS יכול לקחת גם החלטה לחסום את תעבורת הרשת ולעצור את ההתקפה (במידה של זיהוי שגוי – הוא יעצור תעבורה לגיטימית).
החלוקה ל IDS/IPS היא דיי מלאכותית וסביר יותר למצוא כלי שיכול לעשות גם וגם, כאשר בד”כ הוא מעלה התראות, במקרים מסוימים “בודק את המשתמש” (מאט את התשובות אליו או מציג בפניו מבחן Captcha), ורק במקרים קיצוניים – חוסם.
יש חפיפה מסוימת בין WAF או Firewall חכמים ובין IDS/IPS, אבל כפי שציינו קודם לכן בפוסט – יש ייתרון ביתירות הזו בדמות Defense In Depth. כלי אחד שכשל – לא יגרום למערכת שלנו להיות חשופה.

Physical Security – זה גם חלק מהעניין. מקור: onthetech.com
רשת פנימית
ברשת הפנימית אנו מציבים את בסיסי הנתונים שלנו. בסיסי הנתונים הם שרתים שמחזיקים Assets רגישים ביותר (המידע שלנו!) ואנו יודעים לנטר בצורה דיי ברורה איזה תעבורה אמורה להגיע אליהם. במקרה שלנו: רק תעבורה מתוך שרתי הווב/אפליקציה שאישרנו. כל שרת אינטרנט – רשאי לגשת ל DB מסוים מאוד.
אם כן, Firewall פשוט יכול לספק הגבלה הדוקה על הכללים הללו ולאפשר רק את התעבורה הרצויה. בד”כ לא נמצא מוצרי הגנה נוספים ברמת הרשת בתוך הרשת הפנימית – כי התעבורה כבר מסוננת היטב.
סביר יותר שכאן נמצא כלי monitoring (למשל, אבל לא רק HIDS או Agents שונים) שמותקנים על שרתי ה DB עצמם ומנטרים את ההתנהגות על המערכת.

מה הצעד הבא?

מודל ה CIA והעקרונות הנוספים שהצגתי הם הבסיס: הם חשובים מאוד, אבל אין דיי בהם בכדי להכווין אותנו כיצד להגן על מערכת מורכבת.
חשבו על הארגון / המוצר שלכם – האם ברור לכם כבר אילו צעדים מעשיים חשוב לקחת בכדי להגן עליו בצורה טובה מספיק? באיזה עדיפות ובאיזה סדר?
– אני מניח שלא. וגם אם כן – אתם כנראה רואים תמונה חלקית מאוד של המצב.
לשם כך נוצרו מודלים (“Frameworks”) שעוזרים למי שמשתמש בהם לתכנן מקצה לקצה – כיצד להקים ולתחזק מערך הגנה.
למשל, מודל ה NIST Cybersecurity Framework מגדיר את היסודות (cores) הבאים:

לכל יסוד, יש קטגוריה של כללים ו guidelines – איך להשיג אותה, אשר מורכבת מהירככיה של מדריכים שהולכים ונהיים מפורטים כיצד לכסות את התחום.
למשל: אתם רוצים לאבטח את גישת ה SSH לשרתי הפרודקשיין שלכם? אפשר לחפש בקטלוג המדריכים של NIST ולמצוא את NIST.IR.7966 – מדריך בן 50 עמודים שממצה את הנושא עד תום!
המדריך מתאר את עיקרי הטכנולוגיה מאחורי פרוטוקול / כלי SSH, את החולשות, ואת תחומי ההגנה (“Control Areas”) המומלצים על מנת למתן / לבטל את החולשות הללו. למשל:
  • ניהול חשבונות
  • אכיפת גישה
  • צמצום גישה (Least Privilege principle)
  • Audit וניטור
  • ניהול סיכונים (בהיבט ה SSH)
  • זיהוי ואימות משתמשים.

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

הרעיון של רוב ה Frameworks הוא לא להציע רשימה שטוחה של אמצי-אבטחה (Controls) – בנוסח “חייבים את הכל!”.
הגישה הבוגרת היא לאזן בין צרכים עסקיים לאבטחה – ע”פ ניהול סיכונים שמותאם לארגון / מוצר ולצרכים הייחודיים שלו. ע”פ הגישה הזו: ניתן (ולעתים אף חשוב) לקחת סיכונים – כל עוד מנהלים אותם.
מקור: https://rofori.wordpress.com
חוץ מ NIST CSF (קיצור של Cyber Security Framework) – אלו עוד Framework פופולריים קיימים?

לרוב מחלקים אותם ל-3 קטגוריות:
  • Frameworks רגלוטוריים – אותם המדינה מחייבת על ארגונים מסויימים.
    • למשל: HIPAA לארגונים המחזיקים מידע רפואי, SOX – לחברות בורסאיות בארה”ב, NERC CIP – לחברות החשמל בצפון אמריקה, וכו’
  • Frameworks רגלוטוריים למחצה – אשר ארגון מקבל על עצמו כחלק מחוזה / הסדר מסחרי.
    • הדוגמה הכי נפוצה: PCI-DSS של חברות האשראי. אם אתם מנהלים מידע על כרטיסי אשראי ואתם לא עומדים ברמת ההגנה של ה Framework / או בסטנדרטים שלו (למשל: לא יותר מ 1% מהעסקאות שאתם סולקים הם לא-לגיטימיות) – חברות האשראי עלולות להפסיק לעבוד אתכם. עבור ארגונים רבים – זהו עניין קיומי.
    • יש Frameworks קצת פחות ידועים בעולם עריכת הדין, חשבנאות, וכו’.
  • Voluntary Frameworks – שהארגון בוחר לאמץ ביוזמתו בגלל צרכים כאלו או אחרים.
    • ISO/IEC 27001 – הוא ה Framework הנפוץ בתחום, ובד”כ אימוץ שלו כולל הסמכה ע”י גוף שהוסמך לכך (חברות ייעוץ שונות).
      • הוא נחשב בסיסי, נדרש לעתים על מנת להיות ספק של ארגונים גדולים. דיי “מרובע” בתפיסות שלו, בעיקר מסביב לתהליכים.
      • יש לו 2 גרסאות תקפות: 2005 – גרסה מאוד ממוקדת תהליכים (“Plan-Do-Check-Act”) והתיעוד שלהם (למי שמכיר ISO 9000), וגרסאת 2013 – שנחשבת יותר גמישה ומעשית.
    • NIST SP800-53 (נקרא גם NIST 800 series) – הוא תקן אבטחה לו נדרשים גופים ממשלתיים בארה”ב (ועוד כמה מדינות שאמצו אותו כתקן) – אבל גם זמין לכל דורש.
    • (ISC)2 Common Body of Knowledge (CBK) – זה בעצם ה Framework ה”פנימי” של הסמכות ה CISSP – ההסמכה ה”נחשבת” בעולם אבטחת המידע.
    • (DHS Cyber Resilience Review (CRR – עוד Framework אמריקאי (יש רבים כאלו), הפעם של הארגון לבטחון המולדת (DHS).
    • CIS Critical Security Controls (כרגע בגרסה 6.0) – תקן “פתוח”, שנוצר ע”י קבוצה של מומחי-אבטחה בלתי תלויים, וללא מטרות רווח, ש”מחוייבים לחופשיות האינטרנט”.
      • לעתים מזוהה עם חברת SANS – שמסייעת להפיץ אותו.
    • OWASP TOP 10 – זהו לא Framework, אלא ניתוח תלת-שנתי של 10 ההתקפות הנפוצות ביותר על שרתי ווב, מידע פרטי, מובייל, וכו’ (יש מספר גרסאות של הדו”ח). אם אתם רוצים להתחיל עם הבסיס של הבסיס – זה המקום.
    • וכו’ וכו’
אם אתם רוצים להקים מערך הגנה שלם (לא מושלם. שלם) ומאוזן – כדאי להשתמש ב Framework כנקודת התייחסות.
“אני מבין באבטחת מידע, ועובד לפי השיטה שלי” – היא לרוב לא גישה שמגיעים איתה רחוק, אלא אם מדובר במומחה אמיתי, שכבר ה Frameworks הללו מאחוריו. אם יש לכם ספק – שאלו את “המומחה” לאילו Frameworks הגישה שלו דומה, ומה ההבדלים. מעניין.

אם אתם פשוט כותבים תוכנה ומנסים לאבטח אותה, ולא לאבטח ארגון שלם – כנראה ש OWASP זה השלב הראשון, ו ISC^2 / CIS / NIST – הם המקומות להמשיך וללמוד מהם /לקבל מהם מושג וכיוון.

סיכום

המידע הזה עשה לי הרבה סדר בראש כשנתקלתי בו.
במשך שנים הכרתי כל מיני סוגי התקפות (DDOS, ARP Poisoning, או CSRF) – אך לא היה לי כל סדר מה יותר חשוב ממה, ובאיזה אופן כדאי להתגונן.

אני מקווה שהפוסט הזה עשה מעט סדר. עולם אבטחת המידע (“סייבר”) הוא גדול ומורכב. יש תחומי מומחיות של Penetration Testing, איתור וניתוח Malware, מודיעין, Reverse Engineering, ועוד.

אני? אני ניסיתי רק לתת את הבסיס.

שיהיה בהצלחה!

—–

[א] לא קיימת מערכת מוגנת ב 100%, וגם אם תיאורטית היה ניתן ליצור אותה – היא לא הייתה משתלמת עסקית. מחירי האבטחה עולים בצורה מעריכית – ככל שאנו הולכים ומתקרבים ל”אבטחה מושלמת”.

מבוא לאבטחת מידע (“סייבר” ושטויות כאלו…)

אבטחת מידע (Information Security) או בקיצור InfoSec היא הפרקטיקה של הגנה על מידע במערכות, בעיקר מערכות ממוחשבות – אך לא רק.

ממש בשנים האחרונות, הפכו אנשי האבטחה (“גננים”) למשהו אחר לגמרי: אנשי סייבר (“מהנדסי נוף”). Fancy Name שהוא בעצם אותו הדבר.

למתכנת הממוצע, לכאורה, אין צורך להתעסק בנושא: ישנו איזה מישהו מה-IT (“מנהל אבטחת מידע”) שרוכש, מתקין ומנהל את מוצרי האבטחה, ובכלל זו התמחות בפני עצמה: ממש כמו פרודקט, Operations או QA. לא עסק של המתכנתים.

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

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

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

כמו אותם תחומים שהחלו בצוות חיצוני מתמחה (“צוות QA”, “צוות Operations”, או “צוות ביצועים”) – אך “זלגו” חזרה במידה רבה לפתחם של המפתחים, ישנם סימנים שגם אבטחת מידע בדרך לשם.

קצת פרספקטיבה היסטורית

אני ממליץ לכם להשקיע שלוש דקות לצפות בסרטון הקצבי הבא: https://vimeo.com/55183725

הסרטון מתאר את המציאות בשנת 2010 ונוצר ע”י חברת-אבטחה בשם ArcSight שנרכשה מאז ע”י HP. הוא מפגין כמה מהסיכונים המרכזיים באינטרנט לאותה התקופה.

מחשבי זומבי, הם מחשבים שנפרצו (“compromised”), למשל ע”י תוכנה זדונית, ועכשיו הם עומדים לרשות התוקף לבצע התקפות דרכם. רבות מההתקפות מופעלות מתוך מחשבים של משתמשים רגילים.

אני רוצה להתייחס לכמה אמירות מהסרטון:

“10,000,000 (עשר מיליון) התקפות מתבצעות ביום על מחלקת האנרגיה בארה”ב”

ההגדרה של התקפה כאן היא נכונה “משפטית”, אך סביר שתעתע בצופה שאינו מומחה אבטחה.
התקפה שמתייחסים אליה כאן – היא קריאה בודדת ברשת (פרוטוקולי HTTP, ICMP, TCP, וכו’) שכוונתה לגרום נזק. זו יכולה להיות קריאת Scanning (אין בעיה ל Scanner לשבת 24/7 ולשלוח קריאות בכדי ללמוד את הרשת והמערכת שלנו. לרוב הוא יעשה אותן בקצב “מנומס” בכדי שלא יבחינו בו), או ניסיון אקראי לפנות ל API עם פרמטרים שגויים ולראות מה התוצאה.

כלומר: 10 מיליון קריאות עוינות על מחלקת האנגרגיה של מדינה – זה לא כ”כ הרבה: אלו הם לא “10 מיליון תוקפים שניסו באותו היום לפרוץ למערכת”. בכל זאת:

  • כ 30% מהתעבורה באינטרנט היא תעבורה עוינת (מקור). 2015 הייתה השנה הראשונה מזה זמן-רב שיותר תעבורה באינטרנט נוצרה ע”י בני-אדם, מאשר ע”י bots.
  • חשוב גם לציין שרוב התעבורה העויינת איננה יעילה – אלו “יריות באוויר” שרק חלק קטן מהן גורם לנזק כלשהו. בכל זאת – המספרים הם מפחידים!
 
זה לא משחק מחשב!
בקרו ב http://map.norsecorp.com על מנת לראות מדגם מזערי, אך עדני בזמן אמת – של traffic עויין שעובר באינטרנט.
הטראפיק הזה לא עוצר, ולא פוחת, 24/7.

“59% מעובדים שעוזבים את החברה גונבים נתונים בדרכם החוצה”

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

אני מניח שהנתון המאוזן הוא ש “59% אחוז מהעובדים שעוזבים לוקחים איתם גם נתונים ששייכים לארגון”. מי מאיתנו לא עזב מקום עבודה ולא שמר את תיקיית המסמכים הפרטית שלו? האם בתיקייה הזו אין גם גם כמה מסמכים לא-פרטיים? – כנראה שכן. עדיין, ברוב הכמעט-מוחלט של המקרים לא יעשה שימוש לרעה בנתונים הללו.

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

כשבאים למכור מוצר אבטחה, מדגישים את העובדות והסיכונים – שהם רבים: “האם אתם מעוניינים שעשרות ילדים פורעי-חוק מאוקראינה וסין יחזיקו במסמכי עבודה של הארגון שלכם?” היא השאלה. “אם אתם רוצים, למה אתם לא שולחים להם בצורה יזומה? אולי במייל?” – ניתן להוסיף וללבות את האש.

“אם לא – אז שימו כאן 100,000$ ברגע זה, ואנחנו נדאג שזה לא יקרה! יקרה פחות” – היא האמירה שסוגרת את העסקה (לרוב האמירה תהיה קצת יותר מעודנת, כמובן).
מחיר נוסף, שלא תמיד נלקח בחשבון הוא העיכוב שנוצר בזרימת העבודה – בעקבות אמצעי אבטחה (“controls”). אמצעי אבטחה לרוב מוסיפים תקורה על העבודה השוטפת בארגון. לא המון – אבל קצת, וגם את הכמות הזו חשוב לקחת בחשבון.

“385 חברות בארה”ב חוו פריצה משמעותית למערכות שלהם ב 2010″

המספר הזה דווקא לא נשמע כ”כ מרשים. יש לכך 2 סיבות:

  • “כלכלת האבטחה” היא חשיבה שעוזרת להבין את הכוחות הפועלים בעולם אבטחת המידע. לארגונים לא רק שאין אינטרס לפרסם פריצות שנעשו אליהם – יש להם אינטרס ברור להסתיר אותן, ועל כן הנתונים המפורסמים בהגדרה יהיו נמוכים מנתוני-האמת.
  • זו שנת 2010 – המספרים גדלו מאז.

“בתי חולים בקליפורניה נקנסו ב $675K על כך שנכשלו בעקביות להגן על מידע של מטופלים”

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

“80% מהבנקים לא מצליחים לעצור הונאות לפני שהכסף מועבר”

ראשית, האמירה כנראה לא מדויקת. האם 80% מהבנקים לא מצליחים לחסום אף מקרה הונאה? או שהם לא מצליחים לחסום אחוז מסוים (נאמר 10%) ממקרי ההונאה? יש פה כנראה משחק מכוון עם המספרים.

חשוב לי להזכיר שהנטייה הטבעית לחשוב על אבטחת מידע כ Prevention – חסימת התוקף מבעוד מועד, אבל קשת הפעולה של אבטחת המידע היא רחבה הרבה יותר:

  • מודיעין – להאזין לתוקפים וללמוד מה הם מתכננים מבעוד מועד. יש חברות שסורקות פורומים של תוקפים ותמורת תשלום – יעדכנו אתכם במגמות העדכניות אצל התוקפים ו/או כל שביב מידע שהם נתקלו בו שקשור לחברה שלכם.
  • Prevention – בניית קווי הגנה נגד תוקפים פוטנציאלים. שם מושקע רוב המאמץ.
  • Reaction – היכולת להגיב בזמן שהתקפה מתבצעת, ולצמצם את נזקיה. אם ע”י מערכות Alerts ותגובה ידנית, ואם ע”י סקריפטים של תגובה אוטומטית.
  • Forensics (“זיהוי פלילי”) – איסוף ראיות על התוקפים (ע”י audits ולוגים, למשל) בכדי לפעול נגדם בחזרה. אלו יכולים להיות צעדים משפטיים, או התקפת-נגד.
    חשבו על מערכת המשפט: היא לא מונעת שום פשע, אך עדיין יש לה תרומה חשובה מאוד בצמצם הפשע בכך שהיא מענישה פושעים לאחר שהעברה כבר בוצעה.
 
לסיכום ביניים:
 

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

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

מחירון לפרטי כרטיסי אשראי גנובים. מקור: http://cybersolace.co.uk/2016/04/06/hacking-underground-market

מושגים בסיסיים

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

  • פגיעות / חולשה (vulnerability) היא תכונה של המערכת (מערכת תוכנה או מערכת אנושית) שתוקף יכול לנצל לרעה. פגיעויות ניתן “לחסום”- אך יש לכך מחיר. לעתים קרובות לא משתלם מבחינה עסקית או מבחינת “איכות החיים” לנטרל את הפגיעות – ולכן מקבלים אותה גם כאשר היא ידועה.
    • למשל: למטוסים יש פגיעות שניתן לחטוף אותם ולרסק אותם. ניתן “לבטל” את הפגיעות הזו ע”י הפסקת שימוש במטוסים ע”י האנושות – מה שכנראה לא יקרה. אלטרנטיבה נוספת: ע”י בניית מטוסים מצופים בחומר חסין-התרסקות שייקר את עלות הטיסה פי 2000 – מה שגם כנראה לא יקרה.
    • מה שכן עושים הוא למתן (mitigate) את הפגיעות ע”י אמצעים כלכליים יותר: אבטחה בשדות תעופה, הגנה פיסית טובה יותר על תא הטייס, נהלי אבטחה מחמירים יותר במהלך הטיסה, וכו’.
  • איום (threat) הוא סוג מסוים של התקפה אפשרית. פעולה שתוקף יכול לנקוט.
  • סיכון (risk) הוא הסבירות שאיום מסוים יתממש. בכדי שאיום יתממש יש גם צורך בתוקף שיממש אותו – וגם פגיעות שתאפשר את ההיתכנות שלו.
    • למשל: תוקף יכול לבצע “חטיפה והתרסקות של מקרר ביתי”, אך מכיוון שלמקרר ביתי אין את הפגיעות של “התרסקות” – האיום לא יכול להתממש. למקרר ביתי כן יש את הפגיעות של “חטיפה”, אבל המוטיבציה לכזו תקיפה היא כ”כ קטנה כך שאנו יכולים בקלות לקבל עלינו את הסיכון הזה.

2016

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

בלי מאמץ מיוחד, קפצתי לאתר Hackmageddon שמבצע סיכום דו-שבועי של התקפות שהתפרסמו באותה התקופה. הנה כמה highlights ממה שמצאתי במהלך חודש (שבועיים מפברואר + שבועיים ממרץ), ויחסית ל Highlights של 2010:

 

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

הנה כמה דוגמאות שצצות מהזיכרון:

שוב: המאמרים הללו נכתבו ע”י אנשי תוכנה – לא אנשי אבטחה. 

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

לחצו להגדלה

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

 

סוגי תוקפים

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

חלק נכבד מהטראפיק העוין ברשת – מתבצע ע”י “ואנדליסטים”. מעניין לציין שהנזק שהם יכולים לגרום “בטעות” עשוי לעלות על הנזק שהם התכוונו לגרום מלכתחילה.
רוב ההתקפות המשמעותיות (יש אומרים: כ 2/3) – מתבצעות ע”י פושעים.
עוד כרבע – תופסים האקטיביסטים.
רק חלק קטן ואיכותי – מתבצע ע”י מדינות ו/או ארגוני טרור.
Insiders, אנשים שנתנו להם הרשאות בזכות, אך הם ניצלו אותן לרעה – הם לרוב חלק קטן אך בעלי פוטנציאל נזק משמעותי.

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

  • Casual Person – אנשים ללא מומחיות טכנית עדיין יכולים לבצע התקפות. דוגמה קלאסית: Insiders.
  • Script Kiddies – אנשי בעלי יכולות טכניות בסיסיות, המשתמשים (הורידו באינטרנט) בכלים אוטומטיים שמישהו אחר הכין על מנת להפעיל התקפות. הם לרוב לא יודעים כיצד הכלים הללו עובדים אך משמשים כמכפיל כח למי שבנה את הכלי.
  • תוקפים ברמת מומחיות בינונית – אנשים בעלי יכולת לכתוב סקריפטים / קוד והבנה בסיסית בעולם התוכנה, היכולים להמציא התקפות משלהם – לרוב לא כ”כ מתוחכמות או פשוט וריאציה משופרת של התקפה קיימת.
  • “האקר” – זהו במקור תואר כבוד למקצועני תוכנה ברמה הגבוהה ביותר, בעלי הבנה עמוקה בכתיבת קוד, מערכות הפעלה, רשתות נתונים, בסיסי נתונים וכו’ אשר ממציאים ומיישמים התקפות מורכבות ומתוחכמות. את הכלים שלהם הם לעתים מפיצים לכל דורש – וכך מאפשרים את הקטגוריה של ה Script Kiddies.
    המונח “האקר” כבר איננו באמת אקסלוסיבי ומשמש סבים רבים לתאר את הנכנדים שלהם שיודעים להשתמש בגוגל “הוא מצא לבד את האתר של ביטוח לאומי! הוא ממש האקר!!”.
מחירון לשירותי “האקינג” כלליים. מקור: http://cybersolace.co.uk/2016/04/06/hacking-underground-market

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

  • איומים פוטנציאלים מאדם ללא מומחיות טכנית:
    • גניבת רוחב פס – שכן או עובר אורח ש”זולל” לנו חלק מגלישת האינטרנט.
    • SPAM – שליחת מיילים ללא הסכמת המקבל ובכמויות גדולות.
    • גניבת זהות נקודתית – פרסום פוסטים באתרים / רשתות חברתיות בשם אדם אחר וללא ידיעתו / הסכמתו.
  • איומים מצד משתמש טכני פשוט שמשתמש בכלים שניתן להוריד באינטרנט (מה שנקרא Scipt Kiddie):
    • האזנה לתקשורת אלחוטית של משתמשים אחרים ברשת Wi-Fi או בתא סלולרי זהה.
    • גילוי ססמה של משתמש אחר ע”י keylogger (רכיב שניתן לקנות באינטרנט ומחברים בין המקלדת למחשב על מנת להקליט את ססמת החיבור למחשב)
    • ניחוש ססמה של משתמשים לאתרים ע”י שימוש ב Dictionary Attack (ניסוי כמה אלפי הססמאות הנפוצות ביותר).
  • איומים מצד “פושע אינטרנט” (cyber criminal) – אדם בעל נכונות לקחת סיכונים ובעל רמת מומחיות בינונית:
    • Rogue security software – היכולת לספר לאדם שהמחשב שלו נמצא בסיכון אבטחה (זה יכול להיות סתם פופ-אפ מעוצב באתר) ולדרוש ממנו תשלום על מנת לטפל בה. מסתבר שזה שוק לא קטן…
    • טרנד חם חם היום הוא ה”כופרה” (ransomware) שעשתה לאחרונה עליה משמעותית לקהל דוברי העברית. תוכנה שמצפינה למשתמש את הקבצים במחשב – ודורשת תשלום תמונת מפתח ההצפנה.
    • הפצת תוכנות זדוניות (malware – “נוזקה”) למשתמשי קצה. למשל: העלאת משחק או תוכנה נגועה לאתר שיתוף קבצים. התוכנה הזדונית, ברגע שהופעלה יכולה לשלוח לתוקף מידע שנמצא על המחשב (למשל: תיקיית “My Documents” בחלונות) – בתקווה “לדוג” משהו שימושי, או לשמש כבסיס להתקפת Denial of Service ואז בקשת כופר.
    • Phishing – התחזות לאתר לגיטימי, שלעתים נראה 1:1 כמו האתר אליו הם מתחזים על מנת לגנוב מהמשתמשים את הססמאות שלהם (או מקבילה אחרת). אל האתר המזויף ניתן להגיע ע”י קישור בפורום או במייל (קל לביצוע) או ע”י רישום של כתובת דומה מאוד לאתר המקורי שמשתמשים אקראיים יכולים להתבלבל.
      • בווריאציה אחרת: מספיק ה click של המשתמש על מנת לגנוב session של המשתמש לאתר – וביצוע פעולות באתר “בשם המשתמש” (להלן CSRF, Clickjacking)
  • איומים מצד “האקרים”:
    • גניבת זהות מלאה: גניבת ושינוי ססמאות לאתרים המרכזיים של האדם (Gmail, פייסבוק, וכו’). מכאן יש קשת רחבה של אפשרויות: שליטה על המייל מאפשר בד”כ אתחול ססמה וקבלת סיסמה חדשה לאתרים רבים. ניתן לגנוב כסף ושירותים, ניתן לדרוש כופר להחזרת הזהות, או לבצע פעולות לפגוע במוניטין (reputation) של האדם שהותקף – כאשר אותו האדם יתקשה להוכיח שלא הוא העומד מאחרי המעשים.
    • גניבת כמויות של נתונים פרטיים של משתמשים מאתרים עסקיים – ופגיעה במוניטין שלהם, עד פגיעה חמורה ביכולת שלהם להמשיך ולעשות עסקים.
    • בעצם… כל מה שתוכנה יכולה לעשות. בהינתן ההשקעה מצד התוקף, פגיעויות קיימות מצד המותקף, וקצת מזל לטובתו של התוקף.


כדאי לזכור שלאינטרנט יש שלוש תכונות שהופכות אותו לסביבה פורה כ”כ להתקפות:
  • אנונימיות – ניתן לבצע פעולות ברשת האינטרנט בצורה אנונימית. קשה מאוד לאתר את התוקף, וכך מוסרים מהתוקף חלק מהסיכונים של מערכות אכיפת החוק.
  • גישה עולמית – ניתן מכל יעד בעולם, לתקוף כל יעד אחר שמחובר באינטרנט.
    הפורץ המומחה מערבות רומניה היה יכול לתקוף רק כמה יישובים בסביבה, ולא את הבית שלי שבישראל. דרך האינטרנט – כל בית בעולם הופך ל”יעד נגיש”.
    התוקף יכול להתגונן ע”י חוקים מקומיים ו/או חוסר שיתוף פעולה של הרשויות המקומיות.
  • אוטומציה – אם עליתי על שיטה מוצלחת לפריצת דלתות “פלא-דלת” אוכל להשתמש בשיטה על כחצי-תריסר דלתות ביום, ואולי גם ללמד חבר או שניים את השיטה – כך שיכפילו את התפוקה. אם עליתי על שיטה מוצלחת לפריצה ל Gmail אז אוכל כנראה כל יום לפרוץ לאלפים רבים של חשבונות, וגם אוכל ליצור כלי שעושה זאת ולהפיץ אותו באינטרנט לכל דורש (להלן Script Kiddies).
 

סיכום

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

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

שיהיה בהצלחה!