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

כמעט אצל כל חברה שיש לה תשתית מחשבים רצינית עם שרתים (או בענן), בדרך כלל קיימות הפרדות בין חיבורי רשת לאינטרנט לבין חיבורי LAN. שרתים ומחשבים מקבלים כתובות IP פנימיות ולא כל מחשב או שרת מקבל גישה לאינטנט. מבחינת כניסה לא מורשית מבחוץ – בדרך כלל יהיה פתרון Firewall ובחברות שמשקיעות – יהיה כנראה גם פתרון IDS/IPS ואולי עוד כלים נוספים, הכל כדי למנוע פריצה של גורמים זדוניים מבחוץ.

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

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

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

בדרך כלל, לפני פריצה כזו, הם יבצעו תחקיר בסיוע כל דבר אפשרי (ריגול דרך האינטרנט ברשתות חברתיות, ריגול "קלאסי" תוך שימוש בסוכנים שנמצאים בארץ) כדי למצוא מי האנשים שאותם הם הולכים לתקוף במובן הסייבר. הם יחפשו אנשי IT ואם אפשר – אנשים שיש להם כמה שפחות ידע/נסיון בתחום ה-IT אך שיש להם גישה פנימית למערכות, אחד כזה שלמחשב שלו בעבודה יש חיבור לאינטרנט ול-LAN הפנימי, והוא לא ממש שם לב לשינוי בין URL כמו secure.iec.co.il ל-secure.iec.co.il.info (דוגמא פיקטיבית, אין לי מושג ירוק בתשתית של חברת חשמל). נניח שהראשון מפנה ל-ADFS או משהו חשוב אחר. ה-URL השני שנתתי הוא מזויף והפורצים הקימו אותו (כולל העתקה של גרפיקה עד לביט האחרון) כך שאותו איש IT לא יחוש בסכנה ויכניס את פרטיו האמיתיים להיכנס למערכת. (אגב, טריק ששמעתי שמשתמשים בו אחרי הכנסת שם משתמש וסיסמא הוא להציג הודעה של שם משתמש/סיסמא שגויים כדי "לשאוב" שמות משתמש וסיסמאות נוספות מאותו איש IT).

לאחר מכן יעשו נסיונות לגרום לאותו איש IT להוריד קובץ כלשהו להפעיל אותו. בד"כ אותם קבצים לא יזוהו ע"י מערכת האנטי וירוסים כקבצים מסוכנים (יש לפורצים ממומנים תקציב מספיק גדול כדי לקנות את כל האנטי וירוסים ולבדוק את הרוגלות/פורצות שלהן על אותן מערכות אנטי וירוס ולוודא שאף אחת מהן לא "תקפוץ"). במידה ואותו איש IT הוריד את הקובץ והפעיל אותו, המערכת כבר תחפש דרך לצאת לאינטרנט ולהקים Tunnel דינמי שיוכל לשלוח צילומי מסך, RAT, Key logger וכו'. במידה והם לא יצליחו, הם יחפשו דרך לבצע זאת פיזית (המוסד מומחה בזה, לפי מקורות זרים).

מהרגע שאותו קובץ פועל, לפורצים יש בעצם גישה. סביר להניח שהם יפתחו איזו מערכת C&C (ר"ת Command & Control) כדי לראות איך לגשת אל המערכת, ומכיוון שמשתמשי IT רבים משתמשים בתוכנות כמו SecureCRT ותוכנות אחרות המאפשרות גישה במקביל לשרתים, יש עכשיו לפורצים דרך להיכנס למערכות האחרות עם ההרשאות של אותו איש IT ומהמחשב שלו, כך שסביר להניח ששום מערכת מניעה לא ממש תזהה פעילות חריגה. תזכרו – בשלבים הראשונים, הפורצים לא משנים קבצים וקונפיגורציות, הם לומדים.

אז … מה ניתן לעשות כדי להקשות?

יהיו כאלו שיציעו להשתמש ב-Smart Card. רעיון לא טוב, מכיוון שבד"כ ה-Smart Card נמצא בתוך המחשב ולא מוציאים אותו ואת ה-PIN אפשר לתפוס עם key logger. אז הפתרון הזה עף החוצה.

פתרונות אחרים שיכולים לעזור, הם פתרונות שבעצם מבוססים על אימות כפול, תוך שימוש בטביעת אצבע עם ציוד בחיבור USB או באמצעות TOTP (ר"ת Time Based One Time Password) שמותקן על הטלפון הסלולרי. אפליקציה פופולרית לכך (שנמצאת ב-Repo של כל הפצת אינטרנט) היא Google Authenticator (האפליקציה לא מצריכה חיבור אינטרנט).

איך מיישמים זאת? בכמה צעדים, תלוי במערכת:

  • מערכות לינוקס רחוקות עם כניסת SSH: אם נחליט על TOTP עם שימוש באפליקציה כמו ה-Google Authenticator (יש אפליקציות אחרות ויש גם את המפתחות RSA המפורסמים, כולם עושים את אותה עבודה), נוכל לעקוב אחר ההוראות כאן כדי להתקין זאת. משהו שצריך לקחת בחשבון – תצטרכו להעיף מפתחות SSH מקובץ ה-authorized_keys על מנת שה-TOTP יפעל. כך שתנסו להיכנס לאפליקציה, המערכת תבקש ממכם קוד וידוא שיופיע לכם באפליקציה בטלפון (או במפתח RSA הפיזי).
  • מערכות לינוקס/Windows מרוחקות עם כרטיס Yubikey (גוגל בקרוב מוציאה מוצר מתחרה שנקרא Google Titan, גם הוא פתרון מבוסס FIDO2) – בדרך זו יש לחבר ל-USB מפתח ובכל פעם להעביר את האצבע כשיש צורך לבצע אותנטיקציה. השיטה הזו יותר מאובטחת משיטות שימוש בקורא טביעות אצבע שמובנה במחשב). גם כאן, תצטרכו לבצע תהליך התקנה, רק שכאן יש גם שימוש ב-OpenPGP. כל הפרטים נמצאים כאן.
  • מערכות Windows (תוך שימוש ב-RDP): פתרון חינמי אין למיטב ידיעתי, יש פתרון מסחרי שתומך גם ב-TOTP וגם ב-FIDO2, יש פתרון של חברת ROHOS כאן.

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

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

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

רוב הסטארט-אפים צריכים להקים תשתית כדי למכור את המוצר/שרותים. חלק יקימו תשתית בארץ (אם זה מוצר ללקוחות ישראלים) וחלק יקימו בארה"ב (לדעתי שגיאה קלאסית שתיכף אסביר מדוע). מכיוון שרוב הסטארט-אפים צריכים לעבור מסלול זה או אחר להקים תשתית של שרתים, אפליקציות וכו', החלטתי לתת מספר טיפים מתוך נסיון עשיר (15 שנה, המונה דופק) בנושא. הפוסט עצמו הוא פוסט גנרי. זה נחמד אם היית לוקח מאיתנו שרת VPS (כזה, או כזה או כזה), אבל זו לא המטרה של הפוסט ואפשר לעשות את הדברים שאכתוב עליהם אצל כל ספק רציני (רציני – לא אחד שמוכר וירטואליזציה של Virtuozzo כ"מחשוב ענן"!).

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

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

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

אז מכיוון שבהתחלה (הווה אומר: חודשים ראשונים) מי שמשלם על התשתית זה אתה ו/או שותף שלך ואין לך דוד/מכר מיליונר עם סיגר עבה בפה / קרנות כלשהן שמוכנות לשפוך עליך כספים רבים שתשיג אנשי מכירות, פרסום מאסיבי ועוד, תצטרך להתחיל במשהו קטן ורק לאחר שתהיה המאסה תוכל לתכנן מחדש ממש בגדול. במילים אחרות: את התכנון של 3 שרתי אפאצ'י בפרונט, 3 שרתי אפליקציה, 2 שרתי SQL, ו-Load Balancer עם ראוטר וחומת אש עצבנית – כדאי להשאיר לזמן שתהיה לך מאסה גדולה וקבועה.

לכן, כשמתחילים צריך לקחת שרת וירטואלי (עדיין לא יעודי, המחיר של יעודי יקפיץ בעוד כמה מאות דולרים לחודש) טוב עם ליבה אחת (מומלץ 2 אם אפשרי מבחינת תקציב) וזכרון של לפחות 1-2 ג'יגה (אם מדובר בשרת Linux) או 2-3 ג'יגה (אם מדובר בשרת Windows. מה לעשות, Windows שותה זכרון עם צינור). מבחינת רוחב פס, ודא כי הספק נותן לך לפחות 5-10 מגהביט סימטרי (לא "מתפרץ", שזה בעצם טריק שיווקי למכור שליש מוצר במחיר של מוצר) ומתחייב על כך בחוזה. מבחינת דיסק, כדאי שיהיו כמה עשרות ג'יגהבייט בתור התחלה. ודא שיש לך אפשרות לקבל קונסולה אם במקרה נעלת את עצמך בטעות (כמו במקרה של טעות בהגדרות SSH או חוק שגוי בחומת האש הפנימית) מבלי להתחנן לתמיכה שיפתחו לך.

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

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

  • Cache חובה: לא חשוב כמה האתרים שלכם דינמי, חלקים רבים בתוכו הם סטטיים – תמונות, סקריפטים, תכנים, דף פתיחה ועוד, וכל החלקים האלו אפשר ליצור להם קבצים סטטיים שיוגשו לגולש ואפליקציית Cache תייצר אותן תוך מעקב מה בתוקף ומה לא. אם אתם משתמשים באפליקציות CMS, אז ברוב המקרים זה רק עניין של התקנת תוסף פשוט שיתן לכם את זה. שימוש חכם ב-Cache יכול לחסוך את רוב העבודה שהשרת צריך לעשות כדי לתת תכנים מותאמים לגולש.
  • אופטימיזציית SQL – זה משהו אחד שיש לך 2 שרתי SQL מאסיביים שרצים עם סינכרון/רפליקציות עם תקציב שנתי רצינית, וזה משהו אחר שאתה סטארט אפ ויש לך תקציב ששווה לתקציב הקופה-הקטנה של גוגל. שרת ה-SQL שלך צריך לעבוד בצורה אופטימלית וחזקה. אם אתה משתמש לדוגמא ב-MySQL, אז יש כאן לדוגמא מדריך איך לעשות זאת, וכל שרת SQL מכובד כולל אתר שלם איך לעשות אופטימיזציות, החל בבחירת מנוע נכון (InnoDB, MyISAM וכו'), הגדרת כמות חיבורים בהתאם לכמות הזכרון והצורך, ועד ל-Queries בלתי אופטימליים (דבר שגורם "מריבות" בין מפתחים שונים, גם את זה ראיתי).
  • שרת WEB טוב: הנה עובדה – שרת Apache על VPS כמו שפירטתי מקודם שמוגדר טוב (עם כל ה-MPM, מודולים וכו') יכול לשרת כמה אלפי אנשים סימולטנית מבלי לחנוק את הליבה של ה-VPS ומבלי לגרום ל-Load היסטרי. גם שרת NGINX יכול לבצע את העבודה הזו מבלי לחנוק משאבים, כל מה שצריך זה תכנון ובדיקה (לא חסרים כלים להעמיס שרתים). אם פעם אחת יושבים ומגדירים את זה בצורה טובה, אז יהיו לכם לילות ללא יקיצה בגלל שרת קורס. חשוב להגדיר בשרת Cache לדברים שלא הולכים להשתנות כל דקה (לדוגמא: קבצי Header ו-Footer).
  • אבטחה: יודעים מי ינסה לבדוק כמה האתר שלכם מאובטח? המתחרים שלכם, ובמקרים רבים המתחרים שלכם מכאן בארץ. חושבים שלא ינסו לבדוק SQL Injection וכל חור אפשרי? הם בהחלט ינסו, כי זו השיטה הכי טובה לגלות סודות מסחריים שלכם (במיוחד דפים וקבצים נסתרים שמיועדים ללקוחות Beta סגור). לכן כדאי לבדוק את כל הרכיבים כולל אלו שלא תהיה להם גישה מבחוץ. נסו לסרוק את השרת שלכם עם nmap, או SNORT (לא, הוא עוד לא מת) וכלים אחרים, חפשו כלים אחרים, בדקו XSS, נסו לבצע SQL Injection ותקנו את כל החורים.
  • עבדו עם גירסאות יציבות של מערכות הפעלה. ב-Windows זה Non issue, משתמשים ב-2008 R2, בלינוקס לעומת זאת מומלץ שלא להשתמש בגרסאות שמשתנות כל הזמן כמו Ubuntu הרגיל (קח את Ubuntu LTS) או Fedora (קחו CentOS 6 או Scientific Linux 6.1) והקפידו להריץ עדכון לפחות אחת לשבוע.
  • צרו גיבוי מרוחק – כל ספק יכול להבטיח שהגיבוי שלו סוף הדרך, שזה נחמד, אבל עדיף שיהיה לכם לפחות אחת לחודש גיבוי של האתר וה-DB אצלכם בידיים או בשרת מרוחק אחר (זה לא מסובך: mysqldump לבסיס הנתונים, rsync לשאר, להריץ הכל ב-cron ונגמר העניין).

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

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

רק הצלחה!