מלכודת דבש ייעודית - Logmein Honeypot
כחלק ממחקר שביצעתי בשבועות האחרונים בנוגע לזליגת מידע דרך מערכות כגון LOGMEIN , התברר לי שאפילו פתרונות איכותיים כמו ONIGMA וכמו PORTAUTHORITY אינם מספקים מניעת זליגה מלאה , שכן בסופו של דבר המשתמש מצליח להקים קישור לLOGMEIN וכל הפתרונות שניתנים כיום הינם פתרונות ברמת הCLIENT ( אפילו אני הצעתי פתרון שכזה בעבר בפוסט הזה ) אך הפתרונות אינם שלמים והמשתמשים משתפרים מפעם לפעם , והגיוני שכך , לכן החלטתי לתפור פתרון קצת יותר מחוכם - כמובן שאני לא אצליח למנוע מהמשתמשים להתחבר - אבל מנהל אבטחת המידע יקבל ALERT מתאים לאירוע על ניסיון לגישה לLOGMEIN ואפילו יקבל שם משתמש + IP + שאר פרטים מזהים , או בקיצור - Honeypot ייעודי.
ובכן החלטתי לבחון פתרון שאינו מונע ( אגב , בגלל ארכיטקטורת הפתרון הוא כן מונע ... ) ואף ביצעתי במהלך היום האחרון POC בנושא , אשר הניב תוצאות מרשימות . המטרה העקרונית היא למנוע התחברות של מחשב מהרשת שלי למחשב מרוחב באמצעות LOGMEIN , בדרך ההפוכה , מה שמאפשר להוציא מידע החוצה מבפנים ולא בהכרח למשוך מידע מבחוץ ( כמובן שנדרשת יעילות דו כיוונית ).
הרעיון היה בעצם להשתש בFEATURE איכותי שקיים כיום במערכות FW של סיסקו ושל פורטינט ( אני חושב שלעוד יצרנים יש פתרון ) שנקרא DNS ReWrite . ולהקים שרת PHISHING פנימי שישמש כמלקט מידע.
המערכת עצמה - מה יש לעשות :
1. הקמתי שרת על גבי מחשב לינוקס מיושן ( שבכל חברה זרוקים כאלה במחסנים ) ועליו הרמתי MYSQL ושירות APACHE.
2. ביצעתי CAPTURE של המסך הראשי של אתר www.logmein.com והנחתי אותו על גבי שרת הAPACHE שלי.
3. בניתי DB על הMYSQL אשר מכיל את השדות -- IP/USER/TIME/COMPNAME/COUNTER.
4. בניתי סקריפט PHP אשר מקשר משדות הUSER\PASS באתר הLOGMEIN המזוייף שלי אשר ברגע שלוחצים LOGIN - מופנים לעמוד אשר מציין שהשירות אינו זמין ויתאושש בעוד מס דקות , ובמקביל נרשמים כל פרטי המחשב - כלל משתמש הLOGMEIN שהוכנס לתוך מסד הנתונים ( בכל פעם שלוחצים , עולה הCOUNTER כמובן )
5. לחיצה על כפתור ה"FREE DOWNLOAD" לCLIENT יפנה לדף המקביל שהתאמתי מראש ושם לאחר שמשתמש מכניס פרטים , במקום להוריד - אותו מסך בדיוק.
6. המערכת מדווחת בדואר אלקטרוני\SNMP למערכת הSIM הארגונית על אירוע ILP כמובן.
שינויים בתשתית - מה יש לעשות :
1. ( במידה ויש DNS ארגוני , כדאי לבצע גם שם ) הגדרתי DNS TRANSLATION REWRITE אשר מבצע המרה של כל תשובת DNS QUERY על כתובת IP של חברת LOGMEIN - לכתובת של הHONEYPOT שיצרתי.
2. ביצעתי חוק של NAT REDIRECTION אשר מחזיר תעבורה שבכל זאת מכוונת לכתובת הIP האמיתית - בחזרה פנימה לשרת הHONEYPOT.
שימו לב לשרטוט לגבי התהליך עצמו ( ללחוץ להגדלה ) :
מה שקורה בעצם הוא שבכל פעם שהמשתמש פונה לLOGMEIN , או האפליקציה פונה לשם , המערכת מופנית לשרת הHONEYPOT והאירוע נרשם ( הקונספט העיקרי מאחורי HONEYPOT הוא שאין סיבה להתחבר אליו למשתמש לגיטימי עבור אירוע לגיטימי ) וההפניה היא שקופה ככל האפשר כי בעצם מערכת התשתית ( הFW שאמור לבצע רק סינון תעבורה ) היא זו שמייצרת את הסטת התנועה והניתוב הייחודי. ( אגב , מומלץ למקם מערכת זו בDMZ מיוחד ).
דבר נוסף שניתן היה לעשות , הוא להגדיר VLAN עבור השרת , ולהגדיר עליו את כתובת הIP האמיתית של שירות הLOGMEIN , ולבצע ניתוב מתאים כך שהציוד יבין שהכתובת היא ברשת ולא באינטרנט - ולכן התעבורה תוסט , מבלי שיהיה ניתן לזהות את השינוי בסניפר.
העיקרון הוא כזה שמשתמשים סטנדרטיים לא יהיו מודעים בהכרח למשחק שלי ברשת , ולכן לפחות לניסיונות ההתחברות הראשונים - יתפסו , ולכן ניתן יהיה לטפל בהם ברמה מנהלתית ולשלול מהם גישה למשאבים רלוונטיים.
כעת כל שנותר לצוות ההתערבות הוא לבוד את האיוע והמשתמש שסומן ולטפל בו בהתאם למדיניות אבטחת המידע הארגונית.
הסיבה שפניתי לפתרון מסוג זה , הוא האמונה הבסיסית שלי שפתרון רשתי תמיד עדיף על פתרון ברמת התחנה ( זכרו מקרי זיוף נתונים עם CSA או עם CONNECTRA ). לפי דעתי האמיתית אין זה פתרון מושלם או הרמטי , אך הוא זול ומהיר ליישום ובכל סדר גודל של ארגון , ולכן שווה ליישום לכל ארגון.
ובכן החלטתי לבחון פתרון שאינו מונע ( אגב , בגלל ארכיטקטורת הפתרון הוא כן מונע ... ) ואף ביצעתי במהלך היום האחרון POC בנושא , אשר הניב תוצאות מרשימות . המטרה העקרונית היא למנוע התחברות של מחשב מהרשת שלי למחשב מרוחב באמצעות LOGMEIN , בדרך ההפוכה , מה שמאפשר להוציא מידע החוצה מבפנים ולא בהכרח למשוך מידע מבחוץ ( כמובן שנדרשת יעילות דו כיוונית ).
הרעיון היה בעצם להשתש בFEATURE איכותי שקיים כיום במערכות FW של סיסקו ושל פורטינט ( אני חושב שלעוד יצרנים יש פתרון ) שנקרא DNS ReWrite . ולהקים שרת PHISHING פנימי שישמש כמלקט מידע.
המערכת עצמה - מה יש לעשות :
1. הקמתי שרת על גבי מחשב לינוקס מיושן ( שבכל חברה זרוקים כאלה במחסנים ) ועליו הרמתי MYSQL ושירות APACHE.
2. ביצעתי CAPTURE של המסך הראשי של אתר www.logmein.com והנחתי אותו על גבי שרת הAPACHE שלי.
3. בניתי DB על הMYSQL אשר מכיל את השדות -- IP/USER/TIME/COMPNAME/COUNTER.
4. בניתי סקריפט PHP אשר מקשר משדות הUSER\PASS באתר הLOGMEIN המזוייף שלי אשר ברגע שלוחצים LOGIN - מופנים לעמוד אשר מציין שהשירות אינו זמין ויתאושש בעוד מס דקות , ובמקביל נרשמים כל פרטי המחשב - כלל משתמש הLOGMEIN שהוכנס לתוך מסד הנתונים ( בכל פעם שלוחצים , עולה הCOUNTER כמובן )
5. לחיצה על כפתור ה"FREE DOWNLOAD" לCLIENT יפנה לדף המקביל שהתאמתי מראש ושם לאחר שמשתמש מכניס פרטים , במקום להוריד - אותו מסך בדיוק.
6. המערכת מדווחת בדואר אלקטרוני\SNMP למערכת הSIM הארגונית על אירוע ILP כמובן.
שינויים בתשתית - מה יש לעשות :
1. ( במידה ויש DNS ארגוני , כדאי לבצע גם שם ) הגדרתי DNS TRANSLATION REWRITE אשר מבצע המרה של כל תשובת DNS QUERY על כתובת IP של חברת LOGMEIN - לכתובת של הHONEYPOT שיצרתי.
2. ביצעתי חוק של NAT REDIRECTION אשר מחזיר תעבורה שבכל זאת מכוונת לכתובת הIP האמיתית - בחזרה פנימה לשרת הHONEYPOT.
שימו לב לשרטוט לגבי התהליך עצמו ( ללחוץ להגדלה ) :
מה שקורה בעצם הוא שבכל פעם שהמשתמש פונה לLOGMEIN , או האפליקציה פונה לשם , המערכת מופנית לשרת הHONEYPOT והאירוע נרשם ( הקונספט העיקרי מאחורי HONEYPOT הוא שאין סיבה להתחבר אליו למשתמש לגיטימי עבור אירוע לגיטימי ) וההפניה היא שקופה ככל האפשר כי בעצם מערכת התשתית ( הFW שאמור לבצע רק סינון תעבורה ) היא זו שמייצרת את הסטת התנועה והניתוב הייחודי. ( אגב , מומלץ למקם מערכת זו בDMZ מיוחד ).
דבר נוסף שניתן היה לעשות , הוא להגדיר VLAN עבור השרת , ולהגדיר עליו את כתובת הIP האמיתית של שירות הLOGMEIN , ולבצע ניתוב מתאים כך שהציוד יבין שהכתובת היא ברשת ולא באינטרנט - ולכן התעבורה תוסט , מבלי שיהיה ניתן לזהות את השינוי בסניפר.
העיקרון הוא כזה שמשתמשים סטנדרטיים לא יהיו מודעים בהכרח למשחק שלי ברשת , ולכן לפחות לניסיונות ההתחברות הראשונים - יתפסו , ולכן ניתן יהיה לטפל בהם ברמה מנהלתית ולשלול מהם גישה למשאבים רלוונטיים.
כעת כל שנותר לצוות ההתערבות הוא לבוד את האיוע והמשתמש שסומן ולטפל בו בהתאם למדיניות אבטחת המידע הארגונית.
הסיבה שפניתי לפתרון מסוג זה , הוא האמונה הבסיסית שלי שפתרון רשתי תמיד עדיף על פתרון ברמת התחנה ( זכרו מקרי זיוף נתונים עם CSA או עם CONNECTRA ). לפי דעתי האמיתית אין זה פתרון מושלם או הרמטי , אך הוא זול ומהיר ליישום ובכל סדר גודל של ארגון , ולכן שווה ליישום לכל ארגון.
