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

בתאריך 31 מאי, 2016

האם תוספי הגנה של CMS מפורסמים אכן מבטיחים הגנה מלאה מפני פריצות או לא? על מנת שהאתר יעבוד כהלכה ללא שגיאות חובה להבטיח לו הגנה מלאה. בבת אחת חייבים לפעול גורמים כגון WAF-ראשי תיבות של Web Application Firewall או הגנה פרואקטיבית,בקרת תקינות מערכת קבצים(*NIX),מערכת גיבויים מתקדמת,הקשחת לוח בקרה של מנהל האתר ושאר טכנולוגיות אשר מבצעות ניטור ומגנות על אתר מפני פגיעות,בעזרת הגבלת גישה למשתמשים לא מורשים למידע ולוח בקרה של האתר. מעט מאוד מערכות ניהול האתר כוללות בתוכן כלים אשר כן מבטיחים הגנה מלאה מפני הפריצות. במערכות ניהול האתרים הידועות כגוןWordpress,Joomla,Drupal,Magento לא כוללות בתוכן הרבה כלים שכן יכולים להגן לנו על אתר.

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

מה אם מערכת לא כוללת את כל כלי האבטחה?

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

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

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

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

נסתכל על כמה טכניקות מוכרות שההאקרים מיישמים על מנת לפרוץ לאתר:

1.ניצול פרצות אבטחה של תסריטי תוספים ו-CMS

פרצות האבטחה הידועות הינן ArbitraryFileUpload(העלאת קובץ אקראי למערכת אחסון),RCE-ראשי תיבות של Remote Code Execution(ביצוע קוד מרחוק),הזרקת SQL,XSS,XSRF,XXE וכו.

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

2.תקיפת לוח בקרה של מנהל האתר

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

3.פריצה דרך FTP

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

4.פריצה דרך SSH:

ליירט גישת SSH יהיה קצת יותר קשה מאשר FTP,מכיוון שהפרוטוקול מיישם שכבת התעבורה בטיחותית בעלת הצפנת תנועה,אבל בכל זאת אפשרי.אפליקציות של האקרים המתקדמות כמו Intrecepter-NG יכולות לבצע מנהור של תנועה,עם כך לבצע תקיפה מסוג MITM(אדם באמצע),להזריק לתוך SSH נתונים ולתפעל קבצים במערכת אחסון.אבל ישנן דרכים פשוטות יותר וזה כאשר SSH עובד בפורט סטנדרטי 22 ובתוך החשבון סיסמה פשוטה.

5.פריצה דרך "שכנים" לפי מערכת אחסון

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

6.תקיפת לוח בקרה של מערכת ניהול האתר

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

7.ניצול פרצות אבטחה של מערכת ההפעלה ושירותי מערכת אחסון

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

לפי מה שאנחנו רואים להאקר יש המון אפשרויות פריצה.

יעילות ואפקטיביות של תוספי הגנה כנגד הפריצות הנ''ל

סתימת חורים באתר(מניעת ניצול פירצות אבטחה):

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

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

במקרה הזה חור נשאר פתוח ולהגן אתר מפני פריצות לא ייצא.

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

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

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

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

הגנה מפני אפשרויות פריצה אחרות

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

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

נשאלת השאלה,האם יש אפשרויות אחרות של העלאת רמת אבטחה של אתר תחת ניהול CMS?

נחפש פתרון ברמה הרבה יותר גבוהה

הגנה מפני ההתקפות דרך HTTP

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

1.שינוי זכויות לקבצים ותיקיות

2.איסור ביצוע הלא מורשה של הסקריפטים

3.הקשחת מנהל האתר באמצעות שרת

4.ניתוק פונקציות המערכת של PHP

אפשרות ראשונה:

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

בתאוריה זה אכן נשמע מרתק,אבל בפרקטיקה כמה CMS פשוט מפסיקים לעבוד.לכן צריך קצת להחליש הגנה.חלק מקטלוגים חייב להיות נגיש לכתיבה ( במיוחד כל (cache/upload/tmp/backup אבל גישה אליהם דרך HTTP או שצריכה להיות סגורה (DenyFromAll in .htaccess file) או פתוחה לפריקת קבצים מסוימים.יש תוספים להם תדרש העלאת נתונים משרתים חיצוניים,לכן יהיה צורך לאפשר allow_url_fopen=1  ופונקציה fsockopen ב php.ini.

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

 

הגנה מפני פריצה מצד מערכת אחסון

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

1.להפסיק להשתמש ב FTP לא מובטח ולעבור ל פרוטוקול מובטח SFTP

2.ללהרכיב סיסמאות קשות ל FTP ו- SSH.יש לא לשמור אותם ויש להחליפם כל הזמן.

3.לעבוד עם פורטים הלא סטנדרטיים בשביל ההתחברות לפי FTP או SSH

4.לעדכן ולשדרג לוחות בקרה

5.להתקין תלאיי אבטחה על גרעין השרת ושירותיו.

כמה שיותר מהנ''ל נצליח ליישם,כך האתר שלנו יהיה יותר מובטח.

נשאלת השאלה,מה לעשות עם תוספי אבטחה בשביל CMS?האם יש צורך להשתמש בהם?

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

מאמר נכתב על ידי:

Cobweb Security LTD

cobweb-security.com

 

מאמרים נוספים...