להגן על האתר שלך

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

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

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

אם לדוגמא ברגע זה אתה מבין שהאתר שלך אינו נגיש ואתה שומע מהספק שאתה מותקף, אתה יכול לגשת לאתר של CloudFlare, לבחור את הדומיין שלך (אם יש לך מספר דומיינים שמציגים אתרים מאותו שרת – עבור על כל אחד מהדומיינים), ללחוץ על כפתור ה-Firewall ופשוט לבחור "I'm Under Attack", כמו בתמונה הבאה:

cf

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

אבל אפשר להגן יותר (וכאן זה כבר בתשלום של 20$ לחודש ל-CloudFlare) – אם תעשה את המנוי, בדיוק באותו מקום ב-Firewall תוכל גם להגדיר בעצם מי המדינות שיכולות לגלוש לאתרים שלך. אם לדוגמא רוב הגולשים שלך הם מישראל, ארה"ב ובריטניה, אתה יכול לאפשר רק אותם וכל השאר יהיו חסומות, כך שהסיכוי להתקפת DDoS מתקטן באופן משמעותי מאוד.

אפשרות מעולה שקיימת (בחבילה של ה-20$) היא שימוש ב-WAF (ר"ת Web Application Firewall). עם WAF החיים יותר קלים כשצריכים להגן על אתרים רציניים. חלק לא קטן מהתקפות דרך רשתות Botnet הם התקפות שנראות במקרים מסויימים כמו כמות גולשים גדולה שנכנסת, אבל מדובר בהתקפה. הנה דוגמא:

cf2

מי שלא מכיר לוגים של כניסות לאתרים לא יבין מה הבעיה, מי שמבין רואה שיש כאן נסיונות כניסה עם מחרוזות רנדומליות שנועדו לעקוף חוקים שחוסמים כניסה. במקרים כאלו ה-WAF יכול לסייע ולחסום דבר כזה בשניות (תומכי CloudFlare כותבים עבורך את החוק אם תתן להם קובץ access_log או שאתה יכול לכתוב בעצמך). מעבר לכך, חוקי ה-WAF מתעדכנים מצד CloudFlare נון סטופ, כך שאתה מקבל הגנה גם על דברים שאינך מודע אליהם (לדוגמא אם אתה משתמש בתוכנה כמו WHMCS (זו תוכנה שקשורה ל-Billing ואוטומציה של שרותי Hosting), אז בעבר היו מספר פריצות לתוכנה, ועד שיצרן התוכנה תיקן אותם, ב-CloudFlare הכניסו חוקי הגנה ל-WAF ללקוחותיהם, כך שאם מישהו היה מנסה לפרוץ ל-WHMCS שלך, הוא היה נכשל בשעה שאצל אחרים הפורץ היה "חוגג".

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

לסיכום, חשוב לזכור את הנקודות הבאות:

  • עדיף שההגנות לאתרך לא יבוצעו בשרת הפרטי שלך אלא ברמת ספק ה-CDN, ובמקביל – לא מומלץ לאפשר גלישה ישירה לאתר שלך, אלא גלישה רק דרך ספק ה-CDN.
  • אל תסמוך על הבטחות ההגנה של ספק התשתית שלך. במקרים מסויימים הוא יפיל את האתר שלך, ובמקרים אחרים אתה עלול ליפול לתומכים שלא ממש יודעים מה הם עושים. יש להם הגנות מכאן עד הודעה חדשה? זה לא רלוונטי לגביך.
  • הגנה רצינית אינה עניין של להגן על הוורדפרס/ג'ומלה/דרופל שאתרך מריץ, אלא על המון פרמטרים אחרים שחלקם אולי אינך מודע אליהם. מומלץ לשכור מישהו חד פעמית כדי לבצע הערכה ותוכנית מה צריך להגן, מה צריך להסיר ואם אפשר – איך להגיע לביצועים אופטימליים עם הגנה.
  • הגנות טובות גם מצריכות תחזוקה מתמשכת, ולכן כדאי לסגור עם מי שמטפל בך טכנית שגם יעדכן את השרת שלך אחת לכמה שבועות.
  • חשוב: אם האתר שלך חשוב מאוד ו/או מייצר לך רווחים, אל תאחסן אותו באחסון משותף (Shared Hosting). לצערי כמות ההגנה שניתן לבצע על אתר שמאוחסן באחסון משותף היא מאוד קטנה (לא ניתן להגן עליו מ-DDoS, לא ניתן להטמיע WAF "מבחוץ", לא ניתן להגן על המכונה ועוד).

קצת על מתקפות OpIsrael ומה ניתן לעשות – ובזול

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

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

מה שרבים כמובן לא מודעים לכך שאותן התקפות נגד ישראל קורות יום יום, וההתקפות ספציפית בימים שמתרחשת התקפה מאורגנת (תחת OpIsrael או תחת כל שם אחר) היא יותר הזדמנות לכל סקריפט קידי ולכל מי שיש כמה רבעוני ביטקוינים מיותרים – להריץ סקריפטים על אתרים ישראליים שגורמים להשחתת דף ראשי (Defacement), או הוצאת כל ה-DB החוצה שכולל בד"כ שמות משתמשים, סיסמאות, אימייל, טלפונים, ובמקרים מסויימים – פרטי כרטיס אשראי -או התקפות DDoS . במדינתנו חסוכת רוחב הפס מספיקה התקפת DDoS קטנה של כמה ג'יגהביטים כדי להפיל אתרים שמתארחים בארץ וגם אם השרת יחזיק מעמד – ספק האינטרנט בארץ יזום בעצמו ניתוק של השרת (כי מבחינתו – מה הוא צריך את הכאב ראש הזה).

חלק מהבנקים בישראל עובדים בשיטה מעט שונה: ברגע שהם רואים במערכות הניטור שלהם שהם תחת התקפת DDoS שהתשתית שלהם לא ממש תוכל לעמוד בה, הם פשוט מנתקים את עצמם מהתקשורת לחו"ל והופס – אין DDoS. כמובן, העובדה שיש כמה מאות אלפי ישראלים (ולא ישראלים) שצריכים להשתמש בתשתית הבנק כדי לבדוק מצב עו"ש, לבצע העברות וכו' – לא ממש מטרידה אותם. שיסבלו יום אחד, לא נורא…

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

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

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

מבחינת מחיר – ישנם מספר חבילות. ישנה חבילה חינמית שיכולה לסייע לאתרים פשוטים להימנע מהתקפות, אך מומלץ להשקיע בחבילת ה-Pro (שעולה 20$) שיכולה למנוע תקיפות נגד כל מיני תוספים שקיימים באתר. לאתרים רציניים יותר (שמכניסים כסף) אני ממליץ ללכת על חבילת ה-Business שיודעת למנוע DDoS ועוד כמה סוגי התקפות.

לאחר שרכשנו חבילה, נעביר אליה את רישומי ה-DNS שלנו (מבצעים את השינוי היכן שרכשתם את הדומיין) כך שננהל את ה-DNS דרך הפאנל הוובי של CloudFlare. הנה לדוגמא ה-DNS של אתר זה:

cloudflare-dns

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

אם תסתכלו בתמונה לעיל, תוכלו לראות 2 חיצים אדומים שמצביעים על 2 עננים. הסימון הזה אומר שמבחינה חיצונית, כתובת ה-IP שלכם תוחבא ומה שיוצג החוצה זו כתובת IP של CloudFlare (שימו לב שיש ללחוץ על אייקון הענן שיהפך לכתום אחרת כתובת ה-IP שלכם האמיתית תוצג לעולם. כמובן שכדי לגשת לאתרכם דרך SSH או RDP, כדאי ליצור בנפרד רשומה נוספת עם שם לא צפוי או לרשום את זה אצלכם בחברה ב-DNS פנימי או קבצי hosts), כך שמי שינסה לתקוף ב-DDoS את .. CloudFlare, ו-CloudFlare יודעים היטב להתמודד עם DDoS (עד רמה מסויימת, תלוי בחבילה שלך. בחבילת ה-Business אתה לא תקבל DDoS – ויש ל-CloudFlare רוחב פס של כמה טרהבייט). אם נצרף את הגנת ה-DDoS להגנת ה-WAF (ר"ת Web Application Firewall) ועוד כמה הגנות שהם נותנים, אתרכם יהיה די מוגן.

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

אתרים/בלוגים פוליטיים לעומת זאת – יכולים לקבל הגנה מלאה בחינם דרך גוגל בפרויקט Shield. על מנת להצטרף – לחצו כאן.

מבחינת חברות גדולות (חברות ביטוח, בנקים וכו') שצריכות לתת ללקוחותיהם אתרי אינטרנט עם מידע – גם כאן CDN (ללא EDGE ישראלי או עם הגדרות שלא יגיע ל-Edge ישראלי, כך שאם יש התקפה היא לא מגיעה לישראל) יכול לסייע. נכון, הרגולטור לא מאפשר אחסון אתרים/שרתים בחו"ל לעסקים מסויימים, אבל התוכן שאינו מצריך Log In (מה שנקרא Pre Login Content) כבר זמין לכל והתוכן עצמו (והשרתים כמובן) נשאר בארץ ורק עובר דרך CDN, וההתקפות DDoS מבוצעות בד"כ על אתרים עם התוכן הזה, לא על התכנים לאחר Log in, כלומר מה שמגיע ל-CDN הוא תוכן די סטטי שכבר זמין, כך שגם חברות יכולות לקחת את אותו מסלול ובכך בעצם למנוע את הצורך לחסום תקשורת לחו"ל.

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

על Ransomware והתגוננות מפניהם

cryptolockerעדכון 1: כשהכופרה מעיפה את VSS (בסוף הפוסט)

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

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

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

  1. פריצה חמורה אירעה בשרתי צד ג' שנותנים שרותי פרסום לאתרים גדולים ודרך פירצה זו הופצו סקריפטים שרצים בדפדפן שמחפשים כל סוג פריצה שקיים לדפדפנים שונים, ל-Flash, ל-Java ו-JS ושאר דרכים – כדי להוריד אוטומטית Ransomware למשתמש וכדי לגרום לו להריץ אותו. כל מה שהמשתמש היה צריך לעשות זה פשוט לגלוש לאתרים הגדולים (כמו New York Times, BBC, AOL, MSN ועוד) והסקריפט שהיה נטען לדפדפן המשתמש היה כבר רץ ומחפש פירצה.
  2. עד כה רוב תוכנות ה-Ransomware היו משתמשות במפתח פרטי קבוע שהיה חלק מחבילת ה-Ransomware, ולאחר זמן מה יצרני האנטיוירוס ידעו לזהות את המפתח ולהציע ללקוחותיהם דרך לחילוץ הקבצים מבלי לשלם כופר. לאחרונה הדבר שונה ובחלק מתוכנות ה-Ransomware המפתח הפרטי נוצר כל פעם מחדש ומועלה מיד לשרת של התוקף ונמחק מהמחשב, כך שלא ניתן אם הותקן Ransomware כזה לחלץ את הקבצים משום שמדובר במפתח 256 ביט שכיום עדיין אף אחד לא פיצח (אולי ה-NSA הצליחו אבל הם לא מפרסמים כלום בנידון כמובן), כך שמחשב פרטי או מחשב בעסק שחוטף Ransomware כזה, הדרך היחידה לחלץ את המידע – היא לשלם את הכופר לתוקף..

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

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

ניתן לעומת זאת להשתמש בשיטה ותיקה שמיקרוסופט המציאה ממזמן (והורידה חלק מהפונקציונאליות בחלונות 8/8.1 אך החזירה ב-10) והיא ה-Volume Shadow Copy (בקיצור: VSS). בשיטה זו המערכת שומרת Snapshot על כל הקבצים המקומיים (לא ב-XP, שם יש שמירה על קבצי מערכת, לא על תכנים כמו מסמכים וכו')

במידה ובמחשבים מותקנים דיסקים קשיחים, ניתן ליצור Partition נוסף שעליו ישבו ה-snapshots (כדאי לעיין במאמר הזה כדי לבצע את הדברים) או שניתן לבצע Snapshot למערכת NAS (על כך בהמשך) וכך ניתן גם לשחזר קבצים את Snapshot של ה-Volume (עוד פרטים כיצד לבצע mount ל-snapshots ולחלץ מידע – ניתן לקרוא כאן).

אם התכנים נשמרים ב-SAN או NAS, כדאי להפעיל את תכונת ה-Snapshot ב-Storage עצמו (חפשו Volume shadow או VSS) ואז את השחזור ניתן לבצע ישירות מתחנת המשתמש (או ב-Storage, לפי הצרכים). יש לוודא ששרות ה-VSS נראה בתחנת המשתמש (בתחנות מבוססות חלונות 7 ובגרסאות חלונות 8 PRO וכו' אפשר להשתמש בכלי כמו Shadow Explorer לשם כך).

שרתי לינוקס שמשרתים תחנות Windows דרך SAMBA: אם הנכם משתמשים ב-LVM אז תוכלו לבצע Snapshots ולשקף אותם דרך smb.conf בשרת כך שניתן יהיה לשחזר קבצים. ניתן לראות איך לבצע זאת כאן. אם הינכם משתמשים בשרותי ZFS על לינוקס/BSD או סולאריס, אין שום בעיה להשתמש ב-Snapshots שמיוצרים ע"י ZFS ל-SAMBA ואפשר לקחת סקריפט מוכן עם הוראות בקישור כאן.

לסיכום: נזקי כופרה יכולים ליצור כאב ראש לא קטן, במיוחד שאין גיבוי עדכני, אז כמובן שצריך לוודא שגיבויים מבוצעים תדיר (ונבדקים תדיר – הדבר האחרון שאתם צריכים זה גיבוי לא קריא בעת חרום). מומלץ לבדוק ולהשתמש בשרות VSS. נכון, השרות די מוגבל (לא ניתן לבצע את גיבוי ה-VSS לרשת) אבל הוא יכול לשמש כפתרון זול על מנת למגר נזק מכופרות. אם אתם מציעים למשתמשים אחסון תוכן בכונני רשת, ודאו כי ל-storage יש snapshots שניתן לגשת אליהם דרך אפשרות ה-Restore to Previous Versions (אם אין, אפשר לתת למשתמשים Shadow Explorer או לכתוב סקריפט ב-PS שיאפשר שחזור).

כשהכופרה מעיפה את ה-VSS: כפי שציין הגולש גיא אדרי בפורום, רוב הכופרות עוצרות את שרות ה-VSS ומוחקות גיבויים (בהנחה וביטלתם את ה-UAC). במקרים כאלו מאוד מומלץ לחשוב לעבור לכונני רשת שיאחסנו את התכנים (לא את האפליקציות וכמובן לא את ה-SWAP). במידה ואין תקציב לסטורג' לדבר כזה, ניתן לבנות סטורג' זול שיארח כונני רשת (יש לדאוג ל-2 כונני SSD ב-RAID-1 שישמשו כ-Cache קריאה/כתיבה ל-RAID פנימי שיורכבי מדיסקים SATA או NL-SAS). אותו שרת יכול להריץ שרות SAMBA, להתחבר ל-AD ועל השרת הזה ניתן ליצור כונני רשת ולבצע Snapshots לכונני הרשת עם LVM או עם ZFS. במקרה התקפה של כופרה, היא לא יכולה למחוק את ה-Snapshots של כונני הרשת, ניתן גם לבצע Snapshots בתדירות גבוהה (עם ZFS בלינוקס או סולאריס או BSD אפשר גם כל 10-15 דקות וניתן להשאיר כמות גדולה של Snapshots מבלי לחשוש לבעיות ביצועים), כך שבסופו של דבר אם כופרה תוקפת, אפשר לשחזר את המחשב מ-IMAGE, למפות את כונן הרשת, ולשחזר מה-snapshot את כל התוכן אל ה-share של כונן הרשת.

האם חייבים להשקיע ב-DR כמו במערכת פרודקשן?

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

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

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

  • מערכת שהיא Active/Passive – כלומר מערכת הפרוקדשן נותנת שרות ומערכת ה-DR לא נותנת שרות בזמן שהיא "פאסיבית". אף אחד לא מתחבר אליה והחיבור היחיד שיש הוא בין המערכת DR למערכת הפרודקשן עם אפליקציית סינכרון מתמשכת שמעבירה כל ביט בין ה-Storage השונים (ה-Storage שבפרודקשן ל-Storage ב-DR), וסינכרונים נוספים רצים בין שרתים עצמאיים (Active Directory וכו').

הנה מערכת קטנה ופשוטה לדוגמא. יש לנו שרת קבצים גדול שאליו מחוברים עוד 2 JBOD (בתצורת RAID, אפשר לחשוב עליהם כמודולים המרחיבים את המקום הפנוי ב-Storage), נתב, חומת אש, ו-12 שרתים שמריצים מכונות וירטואליות שונות.

mind mapping software

האם אנו צריכים בדיוק אותו דבר למערכת DR?

לעניות דעתי, התשובה תהיה ברוב המקרים "לא". ברשותכם, אסביר:

מערכת DR באופן עקרוני, חוץ מלקבל נתונים מה-Storage ושרותים שונים, רוב הזמן כשמערכת הפרודקשן עובדת, היא לא עושה כמעט כלום. אם ניקח את המושג "DR" במובן הקלאסי, השרתים וה-Storage יושבים במיקום פיזי אחר, אולי בבניין אחר, אולי בעיר אחרת, בחוות שרתים שאינה החווה שלנו ואם נשתמש בה שם כ-Active/Active, החברה תצטרך לשלם לא מעט על רוחב פס, חשמל (מה לעשות, חוות שרתים גובות בערך 150-250% יותר מתעריפי חברת החשמל שאתם משלמים בבניין שלכם).

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

  • שרותי קבצים
  • שרותי גיבוי לצד ג' (אם הפרודקשן מושבת עקב הפסקת חשמל ממושכת, רעידת אדמה, אסון כלשהו וכו' – אין לך לאן לגבות את הנתונים)
  • שרותי אותנטיקציה למשתמשים
  • שרתי אפליקציה (SQL, Exchange, Sharepoint וכו')
  • חיבור אינטרנט

אז כשמקימים את ה-DR, אפשר להקים אותו ולחסוך כספים בדרכים הבאות:

  • לא חייבים לרכוש במיליוני שקלים שרת קבצים. זיכרו – שרת הקבצים ב-DR יתן שרותים לזמן קצר עד שהתקלה תטופל, כלומר זה יכול להיות למשך מספר שעות ובמצב אסון טבע – כמה ימים עד שבועות, לא חודשים עד שנים.
  • מבחינת שרת קבצים – אנחנו צריכים 2 (השני ישמש כגיבוי לראשון כי אין לנו במצב חרום קלטות). עם 2 השרתים אנחנו יכולים להשתמש ב-ZFS ובמקום להשתמש בדיסקים מבוססים SAS יקרים, אנחנו יכולים "להעמיס" דיסקים מבוססי SATA זולים וגדולים (הם זולים – בערך 200$ ל-4 טרהבייט ויש אחריות ל-5 שנים) ובשביל לקבל מהירות נוסיף בין 2-4 דיסקים מבוססי SSD שישמשו כ-Cache. ככל שנעמיס יותר דיסקים SATA על המערכת, מהירות הקריאה תהיה הרבה יותר גבוהה כי אנו ניצור RAID של ZFS עם יותר דיסקים מיכניים, כך שאפשר להגיע בקלות למהירות קריאה של בין 400 ל-800 מגהבייט לשניה (אם אתה משתמש בחיבורי 10 ג'יגה או שאתה מחבר מספר פורטים של 1 ג'יגה).
    שרת הגיבוי לעומת זאת, לא מצריך הרבה השקעה – שוב, אפשר נניח להכניס 10 דיסקים של 4 טרהבייט (SATA), ו-2 דיסקים SSD. רוב התעבורה אליו היא כתיבה ולכן ה-SSD יקבל באופן מהיר את הנתונים וברקע מערכת ה-ZFS תכתוב את הנתונים לדיסקים המכניים.
  • לא חייבים לשים שרתים מהדור האחרון, אפשר לשים שרתים מדור קודם או לפני כן במיוחד אם אתם שוכרים מקום לפי ארונות ולא לפי U בחוות שרתים. ה"סוד" הכי ידוע בוירטואליזציה זה זכרון – ואפשר להשיג בזול זכרון לשרתים מלפני 3-4 שנים.
  • אם לא נעביר את כל השרותים, יהיה לנו מקום "להתפרס" מבחינת השרותים, כך שכמות המכונות הוירטואליות שרצות פר שרת לא תהיה גדולה, וכך נוכל לתת את אותו שרות חרום – במהירות מיטבית.
  • גם מבחינת רוחב פס החוצה מהשרתים למשרדי החברה נצטרך לדאוג ל-Policy כלשהו ש"אין חגיגות" כי במצב חרום לא רק תעבורת אינטרנט מבחוץ עוברת, עכשיו גם כל ה-DATA מהשרתים מבחוץ עוברים על אותו רוחב פס, והדבר האחרון שאתם צריכים זה לא להצליח להיות מחוברים לשרתים בחוץ כי כמה עובדים החליטו שעכשיו בדיוק הזמן לצפות בשידורים חיים לגבי המצב. (פתרון למצב כזה שהרמתי בעבר: PC עם מודם 3G שמצד אחד מקבל שידורים דרך סקריפט, ומצד שני משדר אותם ב-LAN הפנימי דרך VLC תוך וידוא שאין אפשרות להתחבר למודם 3G מבחוץ).

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

בפוסט הבא נדבר על מערכות Active/Active.

טיפים להגנה על האתרים שלך

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

זה לא משנה אם הדעות הפוליטיות שלך הן ימין, שמאל, או מרכז, כולנו יודעים שישראל היא מטרה להתקפות תדירות על כל פיפס שקורה במדינה ושקשור למצב בטחוני, מצב בשטחים וכו'. כל מיני "התקהלויות" שונות קובעים תאריכים כדי לתקוף אתרים שמתארחים בארץ (או בחו"ל) כל עוד יש להם קשר כלשהו לישראל, ולפעמים מספיק שיש לאתר דומיין עם סיומת co.il/org.il/net.il כדי שהאתר יהיה באיזו "רשימת מטרות" להתקפה.

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

אתרים רבים מתארכים באחת מ-2 חבילות עקריות לאירוח אתרים: אכסון משותף (Shared Hosting) ושרת יעודי (בין אם וירטואלי או פיזי). אתחיל באכסון המשותף.

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

אירוח אתר (או אתרים) בשרת פיזי או וירטואלי נותן יתרונות גדולים וברורים כגון:

  • רוחב פס יותר גדול לשרת את גולשי האתר
  • אפשרות לאחסן הרבה יותר אתרים ותתי-אתרים
  • אפשרות לקבוע אלו שרותים ירוצו
  • אתם קובעים את הגדרות האבטחה
  • ועוד ועוד

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

הנה כמה דברים שמומלץ לעשות על מנת למנוע כמה שיותר פריצות לשרתים כאלו:

  1. מומלץ להעביר את התוכן של האתר דרך ספק CDN כלשהו ודרכו בלבד. ישנם 2 ספקי CDN גדולים שאני יכול להמליץ עליהם:  Cloudflare ו-Incapsula. ל-Incapsula יש יתרון שיש להם שרת סופי (Edge) בישראל, אולם כמות הנתונים שהשרות נותן בחבילת החינם היא קטנה מאוד (50 ג'יגהבייט). ל-Cloudflare לעומת זאת, אין מגבלת תעבורת נתונים גם בחבילת החינם. אצל 2 הספקים החבילות המסחריות נותנות הגנה רצינית מאוד נגד סוגים רבים של התקפות כך שכל גלישה לאתרכם (ובמידה והתעבורה של האתר שלכם עוברת דרך אותו ספק CDN) – המערכת תבדוק מהיכן הגולש מגיע, האם זהו גולש אמיתי או סקריפט זדוני, האם זהו נסיון גלישה אמיתי או נסיון לפרוץ לכם את האתר וכו'. למי שיש אתר והאתר יוצר רווחים עבורו, אני ממליץ להתחבר לאחד מספקי ה-CDN כמה שיותר מהר.
    נקודה חשובה שרבים מתבלבלים בה – ספק CDN אינו מארח את האתר שלכם. הוא שומר חלקית עותק מקבצים מסויימים ובכך הוא מאיץ את מהירות הגשת חלק מהדפים לגולש, אך כשמגיעה בקשה לדף מסויים לדוגמא, הוא מעביר את הבקשה לשרת שלכם (למעט מקרים שהשרות מזהה שמדובר בסקריפט זדוני, במקרים כאלו הוא ינקוט צעדים שונים למנוע מהסקריפט לפרוץ).
  2. שרות Mail – שרתים וירטואליים רבים של לקוחות מריצים שרותי Mail כך שהאתר ישלח אימיילים ללקוחות וגם ישלח לבעל האתר הודעות אימייל שונות (אישורים לתגובות, אישורי רכישה מהאתר, הודעות מלקוחות וכו'). במקרים רבים שרות ה-Mail אינו מוגדר בצורה מיטבית או בצורה מאובטחת בצורה מספקת, כך שיכולים לקרות במקרים רבים בעיות של שליחה וקבלת הודעות מייל מכיוון שהשרת נחסם ע"י שרתים אחרים וההודעות שיוצאות מהשרת הוירטואלי יסומנו כ"זבל" (spam).
    אני ממליץ לבטל את שרות ה-Mail המתוקן בשרת ולהשתמש בשרות כמו של חברת Mailgun. החשבון החינמי שאותה חברה נותנת, מאפשר משלוח וקבלה של עד 10,000 אימיילים בחודש. האתר עצמו אינו מארח חשבונות אימייל, אלא משמש כ-redirect, כך שהשרות ישלח את המייל בשם האתר שלכם וכל מייל שיגיע אליכם, יופנה אוטומטית לחשבון מייל שיש לכם.
  3. התחברות דרך SSH: ישנם מאות אלפי סקריפטים שסורקים את רשת האינטרנט למצוא דרכים להיכנס לאתר שלכם, במיוחד דרך חיבור SSH (זהו החיבור שדרכו ניתן לבצע פעולות על השרת שלכם דרך מסוף [terminal]). יש לי 3 המלצות לגבי שרות זה (ההמלצות מיועדות למי שמתחזק את השרת):
    * להעביר את חיבור ה-SSH מכניסה 22 למספר פורט אחר (מעל 1024)
    * לחסום כניסת root ישירות (כך ששימוש ב-root יתאפשר ע"י sudo או su בלבד)
    * לעבור מכניסה של סיסמאות לכניסה עם מפתחות
    * לעבור להשתמש ב-Port Knocking.
  4. שימוש בפאנלים כמו WHM/cPanel או Direct Admin: פאנלים אלו הם פאנלים נוחים לעבודה למי שאינו מכיר לינוקס, אולם הבעיה המרכזית איתם שהם מוגבלים מדי לחסום הגדרות שבעל האתר עושה שיגרמו לכך שהשרת יהיה חשוף לפריצות.
    לכן, אם אתם מתעקשים לעבוד עם פאנל כלשהו, לכל הפחות מומלץ לגשת אל הפאנל מאחורי שרות VPN (כדי שהפאנל לא יהיה חשוף לנסיונות תקיפה). אם יש לכם הרבה אתרים והגדרות שונות שאתם צריכים תדיר, מומלץ במקום פאנל לקחת מישהו שמבין בלינוקס ובאבטחת מידע, כך שהשרת יהיה כמה שיותר מוגן.

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

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

על אבטחת מידע ופספוסים

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

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

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

phoneזהו מכשיר טלפון מבוסס אנדרואיד מתוצרת סינית של חברת Phicomm (עוד שם מדבקה). לטלפון הזה אין תכונות מיוחדות, חוץ מזה שהוא זול בארץ – 469 שקל (ויש לו 1 ג'יגה RAM), ונוסיף לזה עוד 40 שקלים עבור כרטיס מיקרו SD של 8 ג'יגהבייט. המכשיר כבר עם root כך שאין צורך אפילו לפרוץ אותו. כל מה שאני צריך לעשות זה להתקין עליו לינוקס (כ-chroot, כך שלא צריך לפרמט את המכשיר ולהתעסק עם 1001 דרייברים) עם אפליקציה כמו Complete Linux Installer, להוריד את הפצת הלינוקס החביבה עליי ולהתחבר לטלפון עם תוכנת SSH כלשהי (ואם אני ממש מתגעגע לגרפיקה – יש VNC עם האפליקציה).

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

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

אז איך אפרוץ? אני יכול להשתמש בשיטות phishing למיניהם, ואולי אצליח, אבל בשביל מה להתאמץ כל כך? כל מה שאני צריך לעשות זה קצת לעקוב היכן החברה יושבת והיכן אותו מנהל אוכל. אני יכול להגיע לאותה מסעדה, להזמין לי איזו ארוחה ולנצל את העניין שרוב הסועדים מתחברים ל-WIFI של המסעדה. אני יכול לנסות להפיל את הנתב אבל בשביל מה? אני פשוט יכול לקחת את אותו טלפון סיני זול שהזכרתי לעיל ולהכניס את כתובת ה-Gatway של הנתב במסעדה ככתובת IP בטלפון שלי. תודות ל-ARP עם מספר טריקים פשוטים, כל גלישת התעבורה תעבור דרך המכשיר שלי ואני יכול לתת לכולם חיבור אינטרנט.. עם "מתנה" קטנה – אני יכול לסרוק את כל המכשירים – טאבלטים, מחשבים, טלפונים, ולהשתמש בפריצות שיש להם במכשירים (כמובן, אם יש לי גישה ל- zero day exploits אני יכול גם לשתול כל מיני דברים באותם מכשירים). אני יכול "להתחכם" ולא להפעיל את המעקף הזה עד שאותו מנהל יתחיל להשתמש במכשיר שלו ולפי הגלישה שלו לזהות את המכשיר ועליו להפעיל סריקה ונסיונות פריצה, ושוב – לפרוץ למכשיר סלולרי מרחוק אינו דבר כזה מסובך. (תודות לרוב חברות הסלולר, עד שמגיעים עדכוני האבטחה אפשר "לחגוג" לא מעט). מכאן, לא יהיה מסובך למצוא דרך להיכנס למכשירו, להשתמש במגוון החורים כדי למצוא root ולהתקין אפליקציה שתתן לי שרותי טרמינל. באנדרואיד לדוגמא אני יכול להתקין בכלל אפליקציה בצורה מוסתרת כמו webkey (או Prompt ו-VNC ב-iOS) שלא רק נותנת לי טרמינל, אלא גם VNC מלא וכשאותו מנהל יקיש את סיסמתו (או יצייר את ה-Pattern) אני אראה הכל. מכאן, לא חשוב לאן אותו מנהל ילך, אני אוכל להתחבר אליו גם כשהוא בחיבור WIFI וגם בחיבור סלולרי.

לשם מה יש לי צורך להתחבר לסלולרי של אותו מנהל? כי אותו מנהל יתחבר עם Certificate וסיסמא (או רק סיסמא, תלוי במדיניות בחברה) במכשיר שלו, לי תהיה גישה לכל הרשת. כבונוס, לא חשוב מה החברה תריץ כדי לחפש פירצות, הם לא יאתרו מהר את הפריצה שלי כי ההנחה היא שיש וירוס/תולעת במחשב, לא בטלפון. מכאן עד פריצה מהסלולר ל-PC של אותו מנהל המרחק די קצר (ויהיה עוד יותר קצר אם אותו מנהל משתמש ב-USB בחיבור ל-PC שלו). כמה קשה לפרוץ Windows 7/8? לא ממש קשה (שוב, תלוי בגישה שלי ל-zero day). עכשיו אני אאחל הצלחה לאיש אבטחת המידע למצוא את הטראפיק שלי בין ה-PC של המנהל לשרתים ומשם לסלולרי של אותו מנהל (ואם אני ממש רוצה לסבך את איש אבטחת המידע, אני יכול ליצור מעין "Tunnel" בין ה-PC ל-IP של המכשיר הסלולרי של המנהל ומשם לשרת כלשהו שיושב בענן ומשם לפרוקסי ומשם אליי, אבל בסופו של דבר יש לי C&C לא רע בכלל…

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

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

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

  • שרתי WEB – לבדוק את ה-POST (לדוגמא) מהיכן מגיעים נתונים ב-upload ומה הנתונים.
  • קבצי security בהפצות לינוקס.

u2fוהנה עוד המלצה קטנה: תכירו את מפתחות U2F. זו השיטה החדשה לבצע אותנטיקציה כפולה ושיטה זו נתמכת ע"י מיקרוסופט, גוגל וחברות רבות אחרות (כן, כרגיל מי שחסר בתמיכה זה מוזילה..). בניגוד ל"כרטיסים חכמים" שיושבים במחשב הנייח בחיבור USB כאבן שאין לה הופכין, כאן חייבים גישה פיזית למפתח על מנת ללחוץ על העיגול כדי לבצע אותנטיקציה (בגירסה אחרת יותר זולה יש צורך בלהוציא את המפתח פיזית מה-USB ולהכניס מחדש), כך שמחשב עם אותנטיקציה כזו בלבד פשוט לא יאפשר כניסה מרחוק ללא מגע פיזי. הפתרון נתמך בכרום, Windows מק ולינוקס (בלינוקס יש צורך להוסיף שורה ב-UDEV על מנת שהוא יוכר).

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

כמה מילים על פירצת האבטחה של Bash

בימים האחרונים התגלה באג קריטי ב-BASH, באג שעקב בעיית Parsing של משתנים (Variables) מאפשר להריץ קוד זדוני דרך "כל שרות", כפי שתוכלו לראות כאן.

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

נתחיל מה-Web. אם האתר שלך רץ תחת מערכת CentOS או RedHat או SuSE, אז כן – אפשר לפרוץ אם לא תעדכן מיידית את חבילת ה-Bash (פעולת yum update תספיק). שמים לב למשהו? העדכון היחיד הוא ל-BASH, לא לשום אפליקציה אחרת וזאת מהסיבה שדרך BASH המערכת "מרימה" שרותים, וספציפית עם ההפצות הנ"ל מכיוון שבהן ה-Shell (כלומר SH) מקושר ישירות ל-BASH. בהפצות כמו אובונטו או דביאן ה-SH מקושר ל-DASH, כך שמבחינתן זה לא כל כך רלוונטי.

אז עד כאן – העדכון באמת חשוב ויש לבצע אותו.

אבל מכאן ולהיסטריה של Internet Meltdown – המרחק ענק, ברשותכם אסביר.

אם לדוגמא האתר שלך מוגש למשתמשים דרך CDN ואתה מנוי בתשלום ל-CDN כמו Cloudflare העסקי או Akamai או אחרים, הרי שהינך מקבל בחבילה דבר שנקרא WAF (ר"ת Web Application Firewall), ואותו WAF נכון להרגע מעודכן כבר להכיר את הטריק נסיון פריצה עם ה-BASH כך שכל מה שנותר לך לעשות זה להסתכל בפאנל של ספק ה-CDN ולראות איך בזמן אמת מנסים לפרוץ לך … ולגחך. (שימו לב – אני מדבר רק על 2 ספקי ה-CDN הללו. לגבי אחרים – תצטרכו ליצור קשר עם הספק CDN). אני לא טוען שאין צורך לעדכן את המערכת שלך, אלא שאין צורך להיכנס ללחץ.

עדכון החבילה צריך להיעשות על כל הפצת לינוקס. נכון, הפצות מבוססות Debian לא חלה עליהן הפריצה באופן של הפעלת שרות Apache, אבל יש לא מעט שרותים צד ג' שרצים דרך init והשם מפעילים bash בהתחלה (תסתכלו בשורה ראשונה של הסקריפט אם זה משהו שהבאתם מהפצה אחרת). משתמשי אובונטו מוזמנים להסתכל כאן, Debian כאן. אני ממליץ גם להסתכל כאן באתר של רד-האט איך לעדכן וגם איך ניתן לבצע workaround עם mod_security.

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

אז זהו. שלא.

נתבים ושאר ציודים שנותנים ממשק Web אינם משתמשים בד"כ בחבילות שנמצאות בהפצות לינוקס. אף נתב לא מגיע עם Apache אלא אפליקציה אחרת שמגישה דפים ובכל הקשור ל-BASH, בכל הקופסאות משתמשים באפליקציה שנקראת Busybox שמאפשרת לבצע פעולות shell, אך הפריצה הזו אינה חלה עם שום גירסת Busybox.

כך שאפשר קצת לנשום לרווחה.

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

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