ארכיון תגיות: פריצות

כמה מילים על הצפנת סיסמאות ב-DB

פורסם בתאריך על ידי

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

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

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

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

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

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

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

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

השלב הראשון לאחר קבלת פרטי המשתמש, הוא "להמליח" את הסיסמא ומומלץ גם את כתובת האימייל. ב"המלחה" הכוונה להוסיף מספר תווים רנדומלי לפני, או אחרי, או באמצע הקלט שקיבלת, כך שאם הסיסמא שהזנתי היא hello123 אז לאחר ההמלחה היא תהיה hello123#O2j!d%425  (כאשר אחרי ה-3 יהיו ג'יבריש של אותיות רנדומליות שהמערכת תחשב מחדש בכל פעם שמישהו נרשם. אפשר לשפר ולהוסיף ג'יבריש בגדלים שונים [אנחנו פה לאמלל את חיי הפורץ או לא?], ואפשר לשים את הג'יבריש לפני הסיסמא האמיתית [כל עוד היא בגודל קבוע, כדי שתוכלו אחר כך לוודא שהסיסמא תקינה] או באמצע, הכל תלוי בכישורי התכנות של המפתח.

עכשיו, לפני שאנחנו מכניסים את הסיסמא עם הג'יבריש, אנחנו נצפין את הסיסמא עם הג'יבריש יחד. יש כל מיני סוגי הצפנות, אני ממליץ ללכת על AES-256 (חובבי PHP – יש כאן דוגמא). בשיטת הצפנה זו, ישנו מפתח שלכם, ואיתו אתם מצפינים. ההצפנה מומלץ שתיעשה דרך האפליקציה שלכם והמפתח שלא ישב בקוד עצמו אלא במקום םאחר מחוץ לתיקיות הקוד עם הרשאות מצומצמות מאוד. מדוע AES-256? כי זו הצפנה חזקה מאוד מצד אחד, ומצד שני היא לא מכבידה על שרת האפליקציות (כל שרת עם מעבד Xeon מסידרה 5XXX או מעבד i5 ומעלה או כל מעבד של AMD מה-3 שנים האחרונות כולל קידוד ופתיחת AES על הסיליקון עצמו)

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

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

שיטה נוספת היא שיטת ה-Hashing – בשיטה זו אלגוריתם (כמו SHA256) מקבל טקסט כלשהו (כמו סיסמא) והוא פולט מחרוזת שנראית כמו ג'יבריש. הסיסמא עצמה לא נשמרת בשום מקום ולא נכתבת לדיסק הקשיח של השרת. מה שכן נכתב ל-DB הוא הפלט, או כפי שהוא נקרא – ה-Hash. כך כשהמשתמש מנסה להתחבר ומקיש סיסמא, הסיסמא שהוא מקיש גם עוברת את אותו תהליך ואם ה-Hash שנוצר מהסיסמא שהמשתמש זה עתה הקיש שווה ל-Hash שנמצא ב-DB, אז הסיסמא היא נכונה והמשתמש יוכל להיכנס. חשוב לציין – גם כאן ישנם אתרים רבים שמאפשרים לכל מיני פורצים להוריד טבלאות Hash מוכנות, כך שהפורץ יוכל עם GPU חזק וטבלאות – לנסות לפרוץ את ה-DB אחרי שהוא העתיק אותו ולכן חובה להוסיף לאחר הסיסמא ג'יבריש רנדומלי באורך קבוע (נניח 10-20 סימנים שמיוצרים ע"י פונקציית RAND) ולקזז את האורך הזה בקלט הסיסמא שנקלטת מהמשתמש, ואז להריץ פונקציית Hash לפי האלגוריתם שבחרתם. תוכלו לקבל פרטים נוספים ודוגמאות קוד בשפות שונות כאן. שיטה זו היא מעולה לאתרים מסויימים אך ישנם חברות שרוצות דווקא לשמור את הסיסמא עצמה, כך ששיטה זו לא תתאים להן ולכן חשוב לבדוק מה הלקוח רוצה.

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

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

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

על שקרים, פראנויה, מחשבים וריגול סיני

פורסם בתאריך על ידי

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

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

thinkpad w530מ-ZTE ו-Huawei נעבור לחברת ענק סינית אחרת שכולם מכירים: Lenovo. דו"ח חדש שפורסם באוסטרליה מגלה כי ארגונים רבים לא מוכנים להשתמש במחשבי לנובו אם התוכן שמוכנס במחשב הוא תחת הגדרה של "סודי", "סודי ביותר" ומעלה בשל החשד ש… ניחשתם נכון, שהממשל הסיני מחפש לחדור דרך המחשבים הללו אל אותם ארגונים ו"לשתות" את המידע הסודי. לנובו, שגם כך נחקרת ע"י האמריקאים על אותו חשד, טוענת כי היא בודקת את הנושא.

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

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

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

מהריגול נחזור למחשבים של לנובו. האם באמת יש בהם איזו "דלת אחורית" שדרכה הממשל הסיני יוכל לחדור ו"לשתות" את המידע הסודי במחשבים? אני מאמין שלא מסיבה פשוטה אחת: המחשבים הללו הם בסופו של דבר כמו של המתחרים. לנובו לא מייצרים את כל חלקי המחשב, הם מייצרים את המעטפת, הלוח וחלק קטן מאוד מהשבבים (במיוחד את ה-TPM שמיוצר עדיין ע"י IBM). שאר השבבים נרכשים ע"י לנובו מספקים חיצוניים אחרים בדיוק כמו שהמתחרים רוכשים. אני יכול להבין שעניין אחסון חומרים סודיים וכו' הוא דבר בעייתי על מחשבים, אבל זה כבר לא קשור ללנובו. מה שמחשב PC מתוצרת חברה X נותן לך, גם מחשב מתחרה יכול לתת לך.

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

לפני מספר שנים האשימו גופי ממשל כמו רוסיה ומדינות אחרות את מיקרוסופט בכך שקוד ה-Windows שלה כולל דלתות אחרות סודיות ואותן ממשלות איימו להפסיק לרכוש את מוצרי מיקרוסופט. מיקרוסופט נעמדה על הרגליים האחוריות ונלחמה בהאשמות הללו. אחד מהצעדים שמיקרוסופט נקטה – היא שלחה לגופי הבטחון של ממשלות רבות את קוד המקור של Windows כדי שיוכלו לראות בעצמם שאין שום קוד לדלת אחורית, והפרשה הסתיימה. נחזור ל-2013 ולמדליף הסדרתי סנאודן שגילה לעולם משהו פשוט: ה-NSA לדוגמא, לא ממש צריך את הדלתות האחוריות במערכת ההפעלה של מיקרוסופט. הוא מגיש למיקרוסופט צו שחתום ע"י שופט שקשור ל-FISA ומיקרוסופט אפילו לא מערערת. להיפך – מיקרוסופט פיתחה כלים כדי של-NSA וגופים אחרים יהיה קל לשלוף כל דבר שקשור אליה. משתמש ב-Outlook.com? סקייפ? אולי XBOX או שלל שרותים נוספים? מיקרוסופט תשמח לתת כל מידע על איזה אזרח שה-NSA תרצה בלי למצמץ. ה-NSA לעומת זאת לקח את זה הרבה יותר קדימה – כל חברת תקשורת חויבה להקים חדר במרכז התקשורת (של אותה חברה) ול-NSA תהיה גישה תוך 30 דקות מרגע בקשת ההאזנה ומנהלי החברה אפילו לא יכולים לדעת על כך. כך ה-NSA יכולים בקלות לצוטט לכל תקשורת נכנסת ויוצאת מארה"ב. 

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

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

טיפים להגנה על וורדפרס

פורסם בתאריך על ידי

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

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

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

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

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

  • המשתמש הראשי תמיד נקרא admin והוא עם user ID מספר 1, מה שמאוד מקל על סקריפטים לעשות SQL Injection ולשנות את סיסמת ה-Admin ו/או את כתובת המייל ואז אם הפורץ עושה שחזור סיסמא, מייל יגיע אליו ומשם הדרך קצרה מאוד להשתלטות על האתר שלכם, להפוך אותו לספאמר (דפים נסתרים וכו'), לשנות תכנים וכו'.
  • התיקיות עצמן הן Hard coded, תמיד התוכן/תוספים/עיצובים ישבו ב-wp-content, ושוב – סקריפטים משתמשים בזה כדי לפרוץ.
  • הרשאות קבצים פתוחות מדי. שוב, זה אחלה דבר לסקריפטים. מומלץ להסתכל בקישור הזה כדי לראות מה ההמלצות מבחינת הרשאות מומלצות.
  • קבצים חיוניים שאמורים לא להיראות – נראים גם נראים, כמו wp-config.php ועוד. נכון, הם לא מציגים שום דבר שמראים אותם בדפדפן, אבל גם במקרה זה סקריפטים יודעים להשתמש במידע.
  • גירסת הוורדפרס מוצגת, מה שמקל על סקריפטים לדעת היכן נקודות החולשה של האתר
  • המערכת אינה חוסמת נסיונות התחברות שגוים מרובים ל-wp-admin, מה שמאפשר לסקריפטים לרוץ חופשי ולנחש סיסמאות. נכון, זה אולי לא נשמע מזיק (אם כתבת סיסמא חזקה), אבל ראיתי לא מעט מקרים שדווקא עם זה חדרו לאתרים
  • סיסמאות מוגדרות הן חלשות ו-וורדפרס לא יודעת לאסור סיסמאות חלשות.

אלו, על קצה המזלג, בעיות שיש לוורדפרס.

לשמחת כולם, יש פתרון שיכול למנוע את רוב הבעיות שהצגתי והוא נקרא Better WP Security. זהו תוסף שיכול לתקן פאקים רבים של וורדפרס ולתת הגנה כלשהי. יחד עם זאת, התוסף הזה הוא לא פתרון של "שגר ושכח". יש בו מספר אופציות שאם תפעילו, האתר שלכם פשוט לא יעלה או יסגור אתכם בחוץ, לכן אם אתם רוצים להתקין אותו, צרו גיבוי של המערכת, וקראו מה כל אופציה עושה ותחליטו אם להפעיל אותה או לא. לדוגמא: אם יש לכם אתר קיים והחלטתם להפעיל את ההמלצה לשנות את ה-wp-content, תראו שכל האתר שלכם נשבר, כי התוסף לא משנה בתוך ה-DB את החלק של הכתובת לשם תיקיה חדשה. השינוי הזה לדוגמא מאוד מומלץ שמקימים אתר חדש.

עוד תוסף שכדאי לתת עליו את הדעת ה-BPS Security. התוסף הזה נותן חלק מפונקציות שלא קיים בתוסף לעיל, אבל גם לו יש כל מיני Issues, במיוחד אם יש לכם תוסף כמו WP Super Cache (תצטרכו ליצור את ה-Rules מחדש ב-יhtaccess ולפעמים תצטרכו לשנות דברים ידנית בקובץ הנ"ל).

עניין נוסף: במקרים רבים כשיש Defacement, אנשים פונים לספק, הוא משחזר ורבים חושבים שכך נגמר העניין. אז זהו, שלא. בחלק לא קטן מהמקרים ה-DB (ספציפית טבלת המשתמשים) במקרים רבים שונה ושחזור לדוגמא של מערכות WHM/CPANEL לא משחזר DB, כך שאם הפורץ שינה את אחת הסיסמאות או הוסיף את עצמו, אתם תמצאו שאתרכם יפרץ שוב, לעיתים לאחר כמה שעות. לכן, מומלץ לבדוק את טבלת ה-DB לאחר שחזור ולראות איזה משתמשים יש, והאם סיסמתם לא שונתה (יש סקריפטים שמשנים באופן גורף את כל הסיסמאות לדברים כמו admin123).

בהצלחה

בנוגע לאירועי ההתקפה מאתמול

פורסם בתאריך על ידי

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

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

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

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

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

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

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

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

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

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

אשליית אבטחת מידע

פורסם בתאריך על ידי

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

רוב העסקים והחברות עובדים בדיוק באותה שיטה על מנת להגן על עצמם: חומת אש כלשהי בחברה, גישה מבחוץ (אם תינתן) רק דרך VPN, ובמחשבים עצמם מותקן אנטי-וירוס/"חומת אש" של ספק כלשהו (קספרסקי, סימנטק, ועוד), ואם מנהל הרשת לא עצלן הוא יעדכן אוטומטית את העדכונים שמיקרוסופט שולחת בשרתים ובתחנות. בחלק מהחברות ינתן למשתמשים האפשרות להשתמש ב-Admininistrator המקומי, ובחלק מהמקומות זה יאסר והרשאות יחולקו לפי צרכים. בחברות גדולות מבחינת דפדפן אינטרנט מותקן אקספלורר 6 או 7 והוא הדפדפן העיקרי שאיתו עובדים כדי לא לשבור את התאימות לאפליקציות Web הפנימיות (אם כי יותר ויותר חברות משתמשות באקספלורר 8, לא בגלל רצון עז לשדרג דפדפן, אלא בגלל הסיבה שזה מה שמגיע עם Windows 7).

אסתכן ואומר: ב-90% מהמקומות זו הקונפיגורציה פחות או יותר.

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

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

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

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

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

עכשיו ניגש לעבודה. ראשית נקים שרת Web כלשהו אצל אחת מספקי מחשוב ענן. אצל הספקים האלו לא בודקים אותך בשיניים וכל עוד הכנסת פרטים נכונים של מספר כרטיס אשראי והכרטיס עם כסף, הכל יעבוד. לשם כך שלחתי חבר לדואר לקנות לי כרטיס נטען ב-1000 שקל, כך שאם בעתיד יעקבו אחרי הכרטיס הנטען, יגיעו ל-Dead end.

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

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

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

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

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

  • בוא נאמר שאני צריך להיכנס ל-Exchange של החברה (הרי המייל יושב בשרתים, הוא לא נמחק מהשרת). הרישום של השם משתמש וסיסמא נמצאים ב-Registry וקל מאוד למצוא היכן (לא צריך Administrator לקרוא את זה, לכל משתמש יש הרשאת Read Only, ומכיוון שאיני הולך לשנות את הערך, אני לא צריך לכתוב). הסיסמא כמובן מוצפנת, אבל ב-4 שורות קוד (ספרתי) אפשר להפוך אותה לטקסט פשוט. מכאן מה שצריך זה להתחבר לשרת דואר ולשאוב את הדואר, ולא חסר API לשם כך.
  • אין לי אפשרות להיכנס לשרת מייל? אוקיי. אני יכול ליצור ZIP לקובץ PST ולהתחיל להעביר אותו "בתשלומים" דרך ה-Web. אם אעביר אותו בפעם אחת, מנהל הרשת עלול לעלות על כך, ולכן אעביר כל 5 דקות חלק (נניח חצי מגה) של ה-ZIP דרך פורט 80 או דרך הפרוקסי של החברה (בהתאם ל-Registry של החיבור לאינטרנט) בצורה מספיק חכמה כדי שימשיך להעביר גם לאחר שהמחשב כובה והודלק למחרת.
  • אחרי שיש לי את הקובץ, אני יכול כמובן לפרוס ולהנות מהמיילים, אבל אני יכול להמשיך מכאן ולבנות לי מעין Client שיושב במחשבו של הנציג וסרבר שיושב בשרת Web במחשוב ענן. אני מעוניין לראות מה יש בכונן בתיקיה מסויימת? אוכל לשלוח פקודת dir, ה-client יקבל את הפקודה, יבצע וישלח לי אותה בחזרה דרך השרת Web.
  • ואפשר לעשות עוד הרבה דברים….

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

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

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

סוף סימולציה.

אז איך אפשר להתגונן מהדברים האלו? אפשר לעשות כמה דברים:

  • לא סומכים רק על עדכונים. ישנם לא מעל אתרים המפרסמים Disclosure על פריצות חדשות בכל מערכות ההפעלה ואפליקציות. כל מה שצריך זה להירשם ולעקוב אחר העדכונים והכי חשוב ליישם את ה-Work-around שאותן חברות נותנות עד שיצא Patch תיקון. הערכה שלי: 90% מהחברות בארץ לא עושות זאת.
  • הטמעת פתרונות Packet Inspection שיודעות לעשות אנליזה לפאקטים שיוצאים (במיוחד שיוצאים). כלי כזה יכול לעצור משלוח חלקים מאותו קובץ ZIP שאני שולח כמו בסימולציה.
  • פתרון לא כל כך מקובל, אבל חברות גדולות יכולות להכתיב אותו: לקוח רוצה לשלוח חומר? הלקוח יכול לגשת לאתר החברה ו"להדביק" את החומר בדף מיוחד (לשם כך יש את TinyMCE ואחרים המאפשרים הדבקת טקסט עשיר). כך אפשר לשים קורות חיים, הצעות ועוד מבלי לתת לסקריפטים להיכנס פנימה.
  • יישום מנגנון שאינו מאפשר לשום סקריפט לרוץ מתוך קובץ שהתקבל מבחוץ. אל תסמכו על הכלים של מיקרוסופט שיעצרו את זה.
  • הסברה לעובדים: מקבלים מייל "חתוך", מייל מעמית לעבודה עם הצמדה בלי שום הסבר מלווה? שישלחו את המייל לצוות ה-IT שיבדקו אותו, וליתר בטחון תרימו טלפון לאותו עמית ושאלו אותו אם הוא שלח את אותו מייל. אם הוא לא שלח, מישהו מנסה לחדור אליכם.
  • כדאי להסביר לנציגים להיות חשדנים: לא לתת את המחשב למישהו שעכשיו פגשתם.
  • בנקים: בנק גדול מאוד חשוף לטריקים האלו, ואחד מהניתובים בתוך רשימת הניתוב ניתן לצאת דרכה לרשת גם מהמחשבים של הפקידים בבנק. תארו לכם אפליקציה כמו שתיארתי, רק במקום מייל, היא תעשה דברים אחרים, והיא יכולה להוציא ולהכניס מידע. חושבים שאני מדמיין? אני לא. אני רומז לבנק מסויים שדיברתי עליו בעבר שכדאי שיעברו מחדש על טבלת הניתוב שלהם.

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

בקצרה, כמה עדכונים

פורסם בתאריך על ידי

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

  • כתבתי שאלון לאלו המעוניינים לשכור שרת פיזי/וירטואלי ואני ממליץ לשאול כמה שאלות שלא שואלים כדי שלא תקבלו חתול בשק. מומלץ לעיין. (קבצים מצורפים PDF ו-Word)
  • שרות חדש שאני מפעיל בימים הקרובים שמיועד ללקוחות "חץ ביז" וגם ללקוחות של מתחרים: אבטחה נגד כל מיני חולירות (XSS, SQL Injection, פריצות ב-JS ועוד) + שרות CDN, מבלי שתצטרך לשנות כמעט מאומה באתר שלך. מתאים לבעלי אתרים ולחברות סטארט אפ. המחיר יהיה זול מאוד (צריך לסגור מחיר סופי, אז יקח עוד מס' ימים, אני כן יכול להבטיח שזה יהיה בזול). הפרטים העיקריים אפשר לקרוא אותם כאן.
  • לפני מס' ימים כתבתי פוסט על גיבוי חיצוני ברשת, ואז במהלך מייל שפרסמתי שם אנשים פרסמו כמה רעיונות, הצעות ועוד. תודות לכל האנשים, אני מעלה שרות גיבוי חדש שיתן לא רק FTP, אלא תכונות נוספות, כולל תכונות שאהובות על חובבי לינוקס (אני בתוכם). פרטים יפורסמו בימים הקרובים.
  • ויש גם פורום חדש לאלו המתעניינים בפתרונות VPS ושם כולם מוזמנים לפרסם הצעות, לשאול שאלות, להגיב ולהשתתף.

טיפים לאבטחת אתרים (חלק 2 מתוך 2)

פורסם בתאריך על ידי

בחלק זה (החלק השני) אני אדבר יותר על שרתים. חלק זה מיועד לאנשי סיסטם שמכירים מעט ענייני אבטחה וגם לאלו שמכירים טוב סיסטם אך אינם בקיאים בכל עניין אבטחה. שימו לב: מדובר על אבטחת שרתים שנמצאים מחוץ למשרדי החברה (Hosting, Co-Location, VPS וכו'). אלו המעוניינים במידע בסיסי עבור אבטחה כלקוח שיש לו שרת באחסון משותף, כדאי להסתכל בחלק הראשון, כאן.

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

אתחיל מנקודה מעניינת שרבים מאנשי הסיסטם בחברות טועים בה: ההסתמכות על חומת האש של ספק האחסון. מדוע טועים? מכיוון שאין לכם כלקוחות שום שליטה או בקרה על חומת האש של ספק האחסון ותצטרכו לקחת את מילתו בנושא. אם חומת האש תיפול בין אם בצורה יזומה (תחזוקה לדוגמא) או בצורה מפתיעה (פריצה), במקרים רבים אתם לא תדעו על כך מהסיבה הפשוטה שספקי אחסון לא ששים לספר על כך ונדיר מאוד שחברות מוציאות הודעה מסודרת על כך. למען האמת, ב-20 שנה שאני נותן שרותי סיסטם, עוד לא יצא לי אפילו פעם אחת לקבל הודעה מספק אחסון שחומת האש שלו תהיה למטה או שחומת האש למטה מכל סיבה כלשהי. לכן, כששוכרים שרת או ששמים שרת אצל חברת אחסון, חובה להתקין חומת אש משלך, בין אם זה שרת וירטואלי או שרת פיזי. אם יש מס' שרתים אצל ספק האחסון, כדאי לדאוג לחומת אש אחת (לפחות) שתגן על השרתים. איזו חומת אש? פה כבר נכנסים שיקולים של עלות (האם לרכוש חומת אש כמו של צ'ק פוינט לדוגמא), שימוש במוצר מבוסס קוד פתוח (האם לבנות חומש אש על iptables של לינוקס, או להשתמש ב-pfsense מבוסס FreeBSD והאפשרויות רבות) וכו'. כל אחד ושיקוליו, אך חשוב לבנות חומת אש עם מינימום הכרחי של חוקים ולסגור את השאר. למהדרין כדאי להוסיף logging לחומת האש (לוג של תעבורה) ושהלוג ישלח יומית לאיש הסיסטם/אבטחה בחברה.

גישה לשרתים:

אם אלו שרתי לינוקס, מומלץ לשנות את פורט ה-SSH מ-22 לכל דבר אחר, ולא לאפשר כניסה ישירה של משתמש root מרחוק. כדאי להשתמש בתוכנת nmap על מנת לסרוק מקומית את השרת החדש ולבדוק ששרותים לא הכרחיים לא רצים. רבים לדוגמא לא מודעים שהתקנת ברירת מחדל של CentOS או RedHat מתקינה שרות X גרפי, שרות מדפסות CUPS, בלוטות' ושאר מרעין בישין שאותם מומלץ לבטל (ב-CentOS/RedHat לדוגמא, עצירת השרות מתבצעת עם פקודת service וביטול השרות מתבצע עם chkconfig) גם את המצב הגרפי מומלץ לבטל (אפשר לתקן זאת בקובץ etc/inittab/ בשורת ה-id לעבור מ-5 ל-3). יש לוודא כי אך ורק השרותים שאנו זקוקים להם רצים, וכך נחסוך בזבוז משאבים מיותר וסכנות אבטחה פוטנציאליות.

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

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

הרשאות:

אחת מנקודות התורפה שפורצים רבים משתמשים בהם זו נקודת ההרשאות וסיסמאות. לעיתים עושים דברים מבלי לתכנן מקודם ואז יוצרים בשרתים משתמשים חדשים עם הרשאות יותר ממה שצריך, או שקובעים הרשאות ל-DB הרבה יותר ממה שצריך או שהסיסמאות קלות (יחסית) לפריצה: סיסמאות קצרות וצפויות ([email protected]#$, qwerasdfzxcv, 1q2w3e4r, ושאר סיסמאות צפויות). סיסמאות צריכות להיות מורכבות לפחות מ-8 אותיות ומספרים ועדיף גם סימנים. אפשר לכתוב סקריפט שיצור סיסמאות או שאפשר להשתמש בשרות הזה לדוגמא, על מנת לקבוע סיסמאות. במקרים כמו SSH מומלץ לחשוב לעבור משימוש בסיסמאות לשימוש במפתחות ולמהדרין אפשר להשתמש גם עם כרטיסים חכמים. חשוב גם להשתמש בסיסמאות מסובכות בכל הקשור ל-SQL, FTP וכו' ולצערי ראיתי מקרים שפרצו לאנשים בגלל סיסמאות צפויות.

מעקב:

הנה נקודה שהרבה אנשים שחדשים בתחום הסיסטם לא מבצעים: מעקב אחר השרתים. עם לינוקס החיים יותר קליים, יש דבר כמו logwatch המדווח לך מדי יום מה קרה ב-24 שעות בשרתים שלך. מעקב יותר רציני אפשר לעשות עם כלים כמו TripWire ואחרים המאפשרים ניטור לראות אם המערכת שונתה ומי שינה מה (מבחינת כתובת IP וכו'). סוג כלים נוסף שחשוב להכיר ולהשתמש בו הוא סוג ה-IDS (ר"ת: Intrusion Detection System), ובו אפשר למצוא כלים כמו Snort, Saint וכו'. אלו כלים המאפשרים לך לסרוק את השרתים שלך מבחינת פריצות ידועות ולראות האם השרתים שלך ניתנים לפריצה ומה כדאי לשנות/להקשיח. חשוב לזכור: מעקב רציף, "נסיונות פריצה" יזומים ע"י בעל השרת הם חלק מאוד חשוב שמאפשר להגן ביתר יעילות על השרת שלך ועל התוכן שברשותך ובכך לחסוך נזק ואובדן פרודקטיביות.

קוד:

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

סיכום:

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

טיפים לאבטחת אתרים (חלק 1 מתוך 2)

פורסם בתאריך על ידי

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

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

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

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

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

אז מה מומלץ לעשות? הפתרון פשוט אך לפעמים יקר: למצוא מישהו שמבין טוב באבטחת מידע כדי לסרוק את האתר שלך ולתת לך טיפים. אם האתר שלך נכתב "ידנית" ע"י בונה אתרים, אפשר למצוא אנשים ו/או חברות שיעשו עבורך "סריקה" על הקוד של האתר שלך, מה שנקרא בעגה המקצועית Code Audit. אם בונה האתר משתמש בפלטפורמת בניית/ניהול תוכן כמו Joomla/Drupal/WordPress או ניהול חנות וירטואלית עם אפליקציות כמו oSCommerce או Magneto לדוגמא, אז צריך לבדוק שגרסאות האפליקציה הם האחרונות, שהדטהבייס מוגדר להרשאות שצריך בלבד (ולא לתת לכל העולם ואחותו אפשרות יצירה/עריכה/שינוי/מחיקה/grant וכו', טעות שרבים עושים), שההרשאות בתוכנה נכונות וגם בקבצים עצמם. אלו דברים שחשוב מאוד שיבדקו, כי ברגע שהאתר של הלקוח באוויר, יהיו המון נסיונות פריצה.

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

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

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

החלק הבא: על אבטחת שרתים.