בזמן האחרון צצו כמה בעיות אבטחה מוזרות. מה שמוזר בהן זה לא הבעיות עצמן, אלא העובדה שהבעיות הינן בנות מספר שנים, ועדיין תקיפות.
הבעיה הראשונה הינה התקפת Land על חלונות XP. זוהי התקפה בת לפחות חמש שנים, סביר להניח שיותר. התשובה של מיקרוסופט? “זו לא בעיית אבטחה, כי המחשב לא קורס, ואחרי שההתקפה מסתיימת המחשב ממשיך לעבוד כרגיל. תשימו firewall”. מה? איך תריץ שרת אם ה-firewall שלו חוסם את כל הפורטים?
לצורך ההקשר, שליחת packet בודד לכל port פתוח של המכונה יכולה לגרום למכונה להשקיע את כל משאבי המעבד שלה בלשלוח תעבורת רשת לעצמה. תהליכים רגילים לא מצליחים לפעול במהלך כשלושים שניות. ראוי לציין שדבר לא מונע ממני לשלוח חבילה שניה אחרי שלושים שניות. גודל החבילה הוא 40 בתים. אני חושב שכל אחד יכול להבין שלא צריך נפח תקשורת גדול מידי כדי להביא כל חוות שרתים סבירה לידי כניעה מוחלטת.
אבל מה שמעניין פה זה לא התגובה של מיקרוסופט. כבר התרגלנו לזה שמיקרוסופט לוקחת בעיות אבטחה אמיתיות וטוענת שהן כלום. מה שמטריד פה זה שזו בעיה כל כך ותיקה, עד שכבר שכחנו לבדוק אם היא עדיין קיימת.
ולפני שאוהדי הלינוקס מבין קוראי מוציאים את הדגלים, מסתבר שבלינוקס יש בעיות דומות. לא באותה רמה – הפעם מדובר על מישהו שצריך להיות בעל חשבון רשום על המכונה. עדיין, התקפה שאני לראשונה שמעתי עליה ב-1991 (כן, כן, לפני כמעט 14 שנה) עדיין עובדת על רוב ההפצות המודרניות של לינוקס. לא על דביאן.
בניגוד למקרה המיקרוסופטי, לא מדובר פה בבאג בקרנל. מדובר פה בניהול משאבים נכון. אנשי דביאן (גם FreeBSD ו-OpenBSD) כיוונו את המערכות להיות חסינות לבעיה הזו כברירת מחדל. אנשי RedHat, Gentoo ו-Mandrake לא חשבו על ההתקפה הזו כאשר כיוונו את המערכות להתקנה. היא פשוט ישנה מידי.
רק כדי להסביר, fork הינה פקודה שמייצרת תהליך חדש במערכת ע”י שכפול התהליך הנוכחי. fork bomb הינה תוכנית קטנה אשר מייצרת תהליכים בלולאה. למעשה, מדובר בתוכנית הפשוטה הבאה:
#include <sys/types.h>
#include
int main()
{
while(1)
fork();
}
זהו. רק לקמפל ולהריץ כמשתמש פשוט, והרבה מהפצות הלינוקס המודרניות יורדות על בירכיהן. כדי למנוע את ההתקפה, יש להגביל את כמות התהליכים שמשתמשים לא חזקים יכולים להריץ בו זמנית.
אני רק אציין במאמר מוסגר שבעוד שמכונת הדביאן שלי מגבילה אותי ל-4096 תהליכים כאשר אני מתחבר בצורה טקסטואלית, אני לא מוגבל כאשר אני מתחבר בצורה גרפית או דרך SSH. עוד לא בדקתי את היכולת להריץ fork bomb. אני אדווח אחרי שאני אשמור את הנתונים שלי.
צריך להרים פרוייקט של “רשימת קניות” של בדיקות שצריך לעשות על מערכת לפני שמכריזים עליה כשירה לעבודה.
שחר
זו בעיה, אבל לא ממש בעיות אבטחה.
באותה מידה משתמש רגיל יכול לכתוב תוכנית שתתפוס את כל הזכרון, תמלא את כל המקום הפנוי בדיסקים שיש לו גישת כתיבה אליהם במליוני קבצים קטנים (שזה יותר גרוע מאשר קובץ אחד גדול כי גם מספר הקבצים זה משאב מוגבל) וכו’.
במערכות מרובות משתמשים מנהל המערכת אמור להיות אחראי מספיק כדי להבין את הדברים האלו, ולהגביל את המשאבים שמשתמש אחד יכול לקחת., מה שאמור להיות עניין של קונפיגורציה.
אבל זו בדיוק הבעיה. צריך לתת ברירות מחדל סבירות כדי להגן בפני כל הבעיות שאתה מציין.
לדוגמא, כברירת מחדל התיקיות של המשתמשים לא יושבות על אותה המחיצה כמו התיקיות של המערכת (או תיקית הבית של root). אם אתה ממלא את הדיסק, אתה לא מונע מהמנהל להכנס למערכת ולתקן את הבעיה. פה זה מצד אחר.
שחר
ביוניקסים גם אם אתה תמלא את כל הדיסקים כנראה ROOT יוכל להכנס, כי בניגוד לחלזונות קובץ הדפים (PAGE FILE) יושב בהכרח במחיצה אחרת.
לגבי משתמשים עויינים, לא מספיק לשים אותם במחיצה אחרת, כי אז משתמש אחד יכול לדפוק את כל השאר, שזה גם די רע.
יש הגדרות של QUOTA בשביל זה.
לא יצא לי להתעסק עם זה, אבל אני חושב שזה מאפשר להגביל נפח גישה לכל משאב מערכת.
אם תחשוב על זה, כל משאב מערכת לא מוגן הוא בעיה. אפילו מספר קבצים פתוחים בו זמנית, ואפילו המעבד.
לגבי המעבד, המתזמן עושה עבודה מספיק טובה בדרך כלל, אבל נראה לי שאפשר להגביל גם שם את הנתח שכל משתמש מקבל מהמעבד.
העניין הוא שהגבלה של הדברים האלו כברירת מחדל זה דבר די רע מהסיבה הפשוטה שזה מסרס את המערכת לגבי משתמש יחיד.
אם זה דסקטופ, אז המשתמש היחיד לא מקבל גישה מלאה למחשב שלו.
אם זה שרת, אז השרת לא מקבל גישה מלאה למחשב.
המערכת היחידה שצריכה את באמת היא מערכת שמשמשת הרבה משתמשים באמת, ולא בתאוריה.
מצד שני, אני מסכים שצריך לשים גבולות עליונים איפה שהוא בין מגבלות המערכת לבין מה שסביר שמשתמש יחיד ירצה בו זמנית, איפה שאפשר.
מספר התהליכים למשל.
זו באמת ברירת מחדל גרועה, וזה גם פותח דלת לוירוסים שתוקעים את המערכת על ידי שימוש בforkbomb (למעשה, אפשר לייצר וירוס דמוי blaster שמכניס לסקריפט ההתחלה משהו שמריץ forkbombים באופן רנדומלי, אמנם יהיה קל להסיר, אבל זו עדיין בעיה)
עד כמה שהבנתי, קל מאד למנוע את זה על ידי שימוש בulimits.
כרגיל אתה מעוות את המציאות . אין קשר לפורטים פתוחים או סגורים , ניתן לממש את ההתקפה על כל פורט (בין הוא פתוח ובין הוא סגור) כל עוד פיירוול לא מגן עליו .
אם יש לך פיירוול אתה יכול לפתוח פורטים ללא חשש דרך הפיירוול ועדיין להיות מוגן בפני ההתקפה .
סליחה טעות , זה כן דורש פורט פתוח אבל ללא פיירוול .
עזוב את הטעות כרגע בצד, ואני חייב להודות שלא בדקתי איך ההתקפה נראית כאשר יש פיירוול שמאפשר גישה לפורט.
מה שכן מעניין אותי זה אם אני מעוות את המציאות, וזה מנהגי הרגיל, למה אתה קורא את הבלוג?
שחר
יש אצלי תקווה שאולי אני זה שטועה ומעוות את המציאות כדרך קבע, אבל ככל שאני קורא יותר כך התקווה הזו הולכת ונעלמת .
הבלוג שלך (והוא לא היחיד) פשוט מהווה עבורי Reality Check.
רתם
נ.ב גם התגובה של מיקרוסופט לבאג שציינת בבלוג לא הצלחתי למצוא , אשמח לראות את המקור.
אני לא אריב עם "כן אני כן" ו-"לא אתה לא". אני כן אשמח לדוגמאות ספציפיות.
לדוגמא: התלוננת על זה שאני אמרתי סתם שההתקפה דורשת פורט פתוח. התנצלת. איפה, אם כן, אני מעוות את המציאות?
לגבי התגובה של מיקרוסופט:
http://dailymaily.co.il/10-3-2005/EDIT/SafeNet.htm
אני קראתי את הקישור בתוך הקישור שלך ( ל News.com ).
שים לב להבדלים בין מה שאתה כותב למה שכתוב במקור :
מיקרוסופט לא טוענת שלא מדובר בבעיה אלא פשוט אומרת שלא מדובר בבעיה חמורה , למעשה רק אתה טוען שמדובר בבעיה "אמיתית" משום שרוב החוקרים דווקא מסכימים עם מיקרוסופט (ולא רק בקישור הזה) . בקיצר לקחת באג שולי (לא אני אמרתי את זה) וניפחת אותו והוצאת אותו מכל פורפורציה אפשרית .
הייתה לי טעות רק בחלק אחד של המשפט אבל לא בחלק השני , אתה כתבת : "מה? איך תריץ שרת אם ה-firewall שלו חוסם את כל הפורטים?" אבל במציאות אין שום בעיה לפתוח פורטים דרך פיירוול (לצרכי השרת ) בלי להסתכן בבאג הזה . במילים אחרות אין שום בעייה להריץ שרת גם במצב הזה.
רתם
מיקרוסופט אומרת שבעיה שלוקחת 100% CPU ברמת הליבה, כך שתוכנות userspace לא יכולות, באופן פרקטי, לרוץ, אינה בעייה חמורה. אני טוען שזו בעיה לא פחות חמורה מאשר אם היה מתבצע crash למכונה, מכיוון שלכל צורך פרקטי מדובר באותו האפקט.
יש סוגיה שצריך לבדוק, וזה אם הפיירוול של XP חוסם את ההתקפה על פורטים פתוחים. אין לי כרגע XP בהישג יד לבדוק. אתה מוזמן לכתוב פה את מסקנותיך. בכל מקרה, אני מוצא שלהגיד "תשימו פיירוול" זו התחמקות.
תראה, רותם. הנקודה שניסיתי להעביר לא היתה "תראו, יש למיקרוסופט באג". אם זו היתה הנקודה שהייתי מנסה להגיד הבלוג שלי היה מתעדכן לעיתים הרבה הרבה יותר קרובות. הנקודה שניסיתי להעביר היא שמדובר בבאג מאוד מאוד ישן, שהיה אמור להפתר כבר מזמן. בגלל זה לא הבאתי רק את הבאג מחלונות, אלא גם את זה מלינוקס.
לעניות דעתי, הוצאת את חשיבות הבאג לפוסט שלי מפרופורציה. הבאג של חלונות תופס שתי פסקאות, בעוד הבאג של לינוקס תופס שש. הנקודה להבין היא לא שיש באג, אלא שיש באג שידוע כבר המון שנים, ועדיין נמצא שם כברירת מחדל.
שחר
קצת באיחור אבל ….
אם היית מנסח את הפוסט שלך כפי שכתבת כאן את השלוש שורות הראשונות שלך אז לא הייתה לי בעייה משום שמדובר בדעה שלך ועדיין לא חתמת על התחייבות לאוביקטיביות בבלוג שלך. אבל ברגע שאתה מערבב דעה אישית עם מציאות בלי הפרדה ובלי לתת את המאמר המקורי על מנת שהקוראים שלך יכולו לשפוט בעצמם אז אתה מעוות . הבעיה היא לא במספר השורות אלא באיך הדברים נאמרים .
בקשר לפיירוול ,מיקרוסופט לא הצהירה שהיא לא תתקן את הבעיה כך שאני לא יודע למה אתה חושב שמיקרוסופט מנסה להתחמק ,אבל גם בלי קשר, האם אין מספיק סיבות טובות להפעיל פיירוול גם ללא הבעיה הזו ? הלוואי שמיקרוסופט הייתה יכולה להתחמק מכל הבעיות שלה ב"תפעילו פיירוול" ….
בברכה
רתם
עוד פעם, רותם, אני מנסה להמנע מלהכנס לוויכוחים חסרי טעם על כן או לא. אני מסכים שמבחינת חומרה, לא חסרים למיקרוסופט (ולהרבה תוכנות אחרות) באגים הרבה יותר חמורים.
לגבי "מציאות" וכו’ – לא נתתי קישור כי לא היה תחת ידי קישור. אני קראתי את זה בעבר, והייתי צריך לעבור על גליונות ישנים של דיילי מיילי כדי למצוא לך את הקישור מחדש.
אני אציין עוד דבר אחד שלא ציינתי בעבר מכיוון שחשבתי שהוא ברור. כל מה שנאמר בבלוג שלי הוא דעתי, ללא יוצא מין הכלל. גם כאשר אני מביא "עובדות", אילו הן העובדות כפי שאני מבין אותן. למיטב ידיעתי זהו המצב עם כל מקור מידע אחר גם כן.
אני עושה הרבה מאמצים כדי שהדברים שאני מביא כעובדות יהיו כמה שיותר רלוונטים למציאות, אבל אף אחד אינו חסין טעויות, וזהו בסך הכל הבלוג שלי. אז נכון, אני מזדהה פה בשמי המלא, ואני כנראה מספיק מצליח כדי שכאשר אני כן טועה, אתה תכעס עלי כך :-). עדיין כל מה שנכתב פה, מתחילתו ועד סופו, הינו דעה ופרשנות.
כמובן שאותו הדבר נכון גם לגבי מה שנכתב ב-Ynet, "הארץ", וכל מקור מידע אחר, אבל זה כבר סיפור אחר.
חשבתי ש – LAND זה כלי שניתן באמצעותו ליצור התקפות שונות.
באופן ספציפי אני בדקתי את ההתקפה באמצעות hping. אני מעדיף לדעת מה אני עושה.
שחר
משתמשים רשומים יכולים להריץ בד"כ תהליכים דרך cron, וברוב ההתקנות כל ההגבלות לא תקפות. בזמנו הרצתי על שרת לא-שלי תהליך שהתנפח הרבה מעבר להגבלת ה-ulimit שלי ועשה בעיות, והביך אותי. אחרי חקירה גיליתי שהגבלות ה-ulimit ניתנות כשעושים login, אבל cron עוקף את כל השרשרת הזו.
כן, נראה כאילו שהמצב, גם על דביאן, הוא לא מזהיר. אני דיי משוכנע שגם cron עובר דרך pam, מה שאומר שלא צריכה להיות בעיה מיוחדת לגרום לו לכבד את ההגבלות, אבל עדיין.
צריך לנסות להתקין OpenBSD ולראות מה קורה שם. זה קצת קשה, אבל, כי התמיכה ב-VMWare של הדבר הזה לא מדהימה.
שחר
נענה לעצמי.
OpenBSD לא משתמש ב-PAM. יש שם הגבלה של 64 תהליכים במקביל. באופן אישי נראה לי שהמספר הזה נמוך מאוד, אבל אין להתווכח עם תיאו.
ועוד תשובה לעצמי – Windows XP חסין לבעיה אם הפיירוול דלוק, גם אם הפורט פתוח בו. כמובן שלבקש שיצא לוג על העובדה שהוא חסם משהו לא חוקי זה יותר מידי לבקש….
שחר