Confessions Of A Dangerous Mind

The wonderful Starcraft 2 Wings of Liberty has been released earlier this week, and as a hardcore fan of the original game, wanted to get it just as it roll out, which meant the environmental way of downloading a digital copy.

If you happen to know Blizzard ( the magnificent ! ), their distribution tool is based on 2 channels, one which is the direct downloader over HTTP, and the other which is P2P based. which is the main issue when a new game rolls out, since there werent enough ppl that could share parts, and thus rendered the download for me ( in Israel ) to 90Kbps total, which is about 900Kbps under my acceptable ratio.

So i decided to go for the following – first i will download over a VM in the normal way ( so i could share like a normal user ), but i wanted to play right away (why else would i buy at day 0 ? :) so i had a second download running in the same time on my main computer, which i wanted to “tweak”.

The direction for me was to disable the P2P vector on my main computer, so i could download only from the HTTP source, which then climbs the the limits, and so i did.

When looking into the Log in the downloader i found the tracker ( the distributor of the list that is used to connect beteen the P2P users ) and found it to be http://eu.tracker.worldofwarcraft.com

then i ran a DNS Lookup on the FQDN of : eu.tracker.worldofwarcraft.com and got back a single resolution to - 80.239.178.125

In the following step, i configured a Firewall Rule to block any traffic from my computer to that IP Address, in order to prevent the sharing distribution.

The result was easy , the few seconds after the rule as been configured, the P2P connections dropped, and the entire download reverted to HTTP, which then made the download climb to 500KBPS, and eventually to 1.1MBPS

so i still let the VM download, so i would share the bits to let other users play, but i also started enjoying this fantastic game right away!.

Way to go Blizzard !

Labels: access, concepts, english, guide, starcraft

Posted by barry at 12:10 PM | Link | Comments

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

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

1. משתמשי LINUX לא יצטרכו להגדיר חייגן , אלא פשוט לקבל DHCP מהמודם

2. כדי להחליף כתובת IP חוקית , יצטרך משתמש לשנות את כתובת הMAC אצלו בכרטיס ולאתחל את המודם.

3. זיהוי משתמשים אינו על פי שם משתמש מקומי אצל ספקית האינטרנט , כלומר על מנת לזהות משתמש , יש להצמיד את קו הHOT שלו למשתמש ולIP ברמת הACCOUNTING של ספק התשתיות ולא של הISP. אחכ הנתונים מועברים לכיוון הISP לצורך מתן שירותי ערך מוסף..

4. נתבים מתקדמים יותר אשר בגלל סטנדרטים אינם תומכים PPTP כחייגן , יוכלו לשמש עכשיו כל משתמש ביתי. לדוגמא משתמשים ביתיים יוכלו לרכוש קופסאות FortiGate 50B Wireless שבעיני הוא ציוד התקשורת הביתי המתקדם ביותר היום ( בהמשך השנה אמורה לצאת קופסא יותר קטנה ).

אותי מעניינים כאן מספר נושאים.

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

2. האם יהיה OUTAGE ברשת מבחינת כמות משתמשים מחוברים לHOT למשך אותו שבוע שבו יהיה השינוי ? כלומר האם אני צפוי לראות שבוע של אפלה בו אני יכול להתחבר לרשת נקיה ממשתמשים ולהגיע לרוחבי פס נקיים מול חול ?

3. האם תהיה נהירה של לקוחות Open-Access ( ללא חייגן ) של בזק בינלאומי לכיוון ספקיות אחרות ?

 

מעניין.

Labels: access, changes, news, provider, report

Posted by barry at 8:20 AM | Link | Comments

ואחרי כותרת מפוצצת שכזו וכמובן אחרי שתפסתי את תשומת הלב שחיפשתי - אפשר להתחיל לדבר.

בתקופה האחרונה יצא לי לחקור רבות אודות טכנולוגיות FW שונות ומוטציות שהן עברו מאז שהומצא מנגנון הStateful Inspection ( נסמן כ "SI" כשנדרש ) וכמובן הטכנולוגיות הללו התפתחו ולקחו את עולם הNetwork Firewall לעולמות רחוקים ומתקדמים יותר , שהופכים את הטכנולוגיות

ראשית, מהו Stateful Inspection :

באופן מאוד מאוד כללי , מדובר בטכנולוגיה אשר מתבססת על טבלאות הנקראות State Tables אשר מכילות את פרטים אודות כל TCP Stream שעובר דרך המערכת. למעשה , עבור כל SESSION נשמרים פרטים מזהים אודות חלון הTCP והפרטים השונים לגבי המשך הSESSION , ולכן כל פאקט חדש שיגיע יבדק אל מול הטבלה למציאת שייכות , אם שייך - יועבר למנוע הROUTING , אם לא - יבדק אל מול הRULEBASE של אותה מערכת FW. המאפיין הכללי כמובן הוא מקור , יעד , ופורט. הומצאה במקור על ידי CheckPoint

ובכן לפני מספר שנים בודדות , עם עליית טכנולוגיות הUTM , התווספו מספר מנגנונים לעולם הSI שעיקרם הוא הDPI או בפירוט - Deep Packet Inspection. הרעיון מאחורי הקונספט הוא - להשתמש במנגנוני Content Inspection כאלו או אחרים , על מנת לוודא שהPACKET אכן תקין ונקי ממזיקים , ולשמש כשכבה נוספת במנגנון ההחלטה לגבי הכנסה לState Table. במקרה של DPI אגב , הסריקה ממשיכה להתבצע לכל אורך התהליך בכדי לשמור על תעבורה נקיה ככל האפשר. מה שכבר הופך את טכנולוגיית הSI כריקה ולא משמעותית , כי ההסתכלות צריכה להיות מעבר לLayer 4 ויותר לכיוון Layer 7. ולשם צריך לכוון.

עד היום למעשה כל FW עדיין מבסס חוקים על פי Source/Dest/Service מבלי באמת להסתכל לתוך אותו הService. וכאן בעצם הבעיה , למרות שהקונספט עובד ועובד טוב, הוא כבר לא מספיק מעמיק בשביל להתמודד עם התקפות מתפתחות שעוברות מוטציות בין שכבות שונות במודל OSI.

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

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

מה באמת רץ לנו ברשת ?

הBUZZWORD שמתפתח מעולם זה הוא בעצם יצירת דור חדש ( דור 6 ? ) של מערכות FW אשר מוסיף תווך נוסף למערכת ובעצם מהווה האבולוציה האמיתית של עולם ה FW וגורם לSI לקבל את התגית Obsolete. ולמה בעצם - דור חדש של מערכות FW עולה וצף , Application Aware Firewall או בשם אחר Application Categorized Rule Based Security . והכוונה מאוד מעניינת ( ובעלת המון טכנולוגיה מאחוריה ) הקונספט הוא כזה שבו כל STREAM של אפליקציה ניתן לזהות לפי מבנה הPACKETS או מבנה של מספר PACKETS ולהשוות למול DB כזה או אחר , ובכך בעצם לתת משמעות לעמודת הService בחוקי הFW. כלומר - מידע יעבור מעתה לפי 4 שדות שונים - source/destination/port/APPLICATION .

אגב , ברור שפתרונות מסוג זה לא ניתן לבצע בתוכנה בלבד, יש צורך במעבדים מיוחדים ובחומרה שנבנתה במיוחד למטרה זו . קחו למשל אינטגרציה בין סביבת PGP לסביבה שכזו - המערכת צריכה להיות מקושרת עם הKeyring הארגוני , בשביל לפתוח את ההצפנות השונות שעוברות ברשת ולבצע ניתוח למידע המוצפן.    - הOverhead ברשת הוא מטורף, הLatency בלתי נסבל - ולכן הפלטפורמה תמיד מבוססת ASIC ואפיקי BUS אדירים.

גישה מעניינת היא האם יש צורך בהפעלת PROXY LAYER במערכות אלו , או לעבוד בSTREAM מבחינת עומסים , ובעצם עד כמה עמוק אנחנו צריכים לסרוק את התעבורה , אם אנחנו כבר יודעים שזו אכן האפליקציה שלנו , ויתרה מכך - שהיא מתנהגת כפי שרצינו. השקיפות פה נפלאה - כי אני יכול לדעת בעצם כל אפליקציה שעובדת ברמה רשתית אצלי בארגון , ולקבוע מדיניות בLEVEL אחר לגמרי.

Labels: access, design, solution, technology, thesis, threats, utm

Posted by barry at 12:02 PM | Link | Comments

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

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

חומרה נדרשת :

המפרט אשר אני ממליץ עליו לצורך הקמת שרת ביתי שכזה :

• מחשב מדף פשוט עד 1000 ש"ח ( ניתן לקנות בכל חנות אינטרנט ) עם בקר SATA ומפרט בסיסי.
• להוסיף הרדיסק SATA לפי הצורך - אני ממליץ 500GB של WD ( בערך 500 ש"ח ).
• להחליף קירור בקירור שקט של 12" למאווררים - ( כ50 ש"ח ).
• כרטיס רשת 10/100 כלשהו, עדיף Intel בגלל התמיכה ללינוקס ( כ 35 ש"ח )

החומרה שלי ( הייתה קיימת , ולכן השתמשתי ) :

אני השתמשתי ב : מחשב VIA EPIA 1200 פשוט עם 256MB זיכרון ( אולי אגדיל ) דיסק קשיח 40GB למע' הפעלה ( IDE ) בקר PCI עבור כרטיס RAID של Sweex ( בחומרה ) שאליו מחוברים 2 דיסקים של 500GB בRAID1 ( זה כי אני תמיד מגזים ) וכמובן ממשק רשתי פשוט של 10/100 של INTEL.

LINUX :

כדאי לדעת צעדי לינוקס בסיסיים בכי להשתמש במדריך הזה , בכדי להקל על עריכת קבצים וההתקנה אותה אין בכוונתי להסביר כאן. לצורך ההקמה נשתמש בCENTOS LINUX 5 אשר ניתן להוריד בחינם מהקישור הבא mirror.isoc.org.il . שימו לב , יש להוריד או DVD או 6 דיסקים , למרות שלא נצטרך את כולם. אגב, כל גרסת לינוקס תתאים. -- יש להתקין את הלינוקס נקי לחלוטין , ולדעתי אין צורך בFIREWALL עליו.

SAMBA :

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

יש להתקין את samba על המחשב , ולהקפיד על גרסה אחרונה כמובן ( בסביבת REDHAT\CENTOS\FEDORA הפקודה היא yum -y install samba )

כעת יש להוסיף משתמשים למערכת , לצורך העניין נקרא למשתמש linuxshare במדריך זה ( למי שלא זוכר , מוסיפים משתמש זה על ידי useradd -m -G users -s /bin/bash linuxshare ) אסמן את שם המשתמש עם קו תחתי מעכשיו , שיהיה קל לשים לב ולשנות בהתאם.

יש לקבוע למשתמש החדש סיסמה על ידי passwd linuxshare

כעת יש לערוך את הקובץ - etc/samba/smb.conf/ אשר מכיל את הקונפיגורציה המתאימה לאפליקציה ויש להכניס את השורות הבאות.

# general definitions
[global]

workgroup = MSHOME
server string = My File Share
log file = /var/log/samba/log.%m
max log size = 50 

# security config
security = user
hosts allow = 127.0.0.1 192.168.1.0/24
hosts deny= 0.0.0.0/0

# server password file
encrypt passwords = yes
smb passwd file = /etc/samba/smbpasswd

# shares
[FileServer]
comment = File Server Share
path = /home/linuxshare
valid users = linuxshare
public = no
writable = yes
printable = no
create mask = 0765

הערה : שימו לב לשורת הhosts allow , אשר משמשת כמעין IP FILTER שמאפשר התחברות רק מכתובות הרשת הרלוונטית , יש לשנות בהתאמה , כמובן את 127. רצוי להשאיר כי מדובר בloopback

כעת עלינו להעתיק את קובץ הסיסמאות של מע' ההפעלה בכדי לשייך את המשתמשים הקיימים במערכת למערכת הSAMBA שלנו על ידי -

cat /etc/passwd | mksmbpasswd.sh > /etc/samba/smbpasswd
chmod 600 /etc/samba/smbpasswd

כעת עלינו לקבוע סיסמת משתמש השיתוף על ידי הפקודה

smbpasswd linuxshare

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

service smb start
/sbin/chkconfig --level 345 smb on

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

אולי הייתי מוסיף גם CLAMAV בתור אנטיוירוס שיסרוק כל העתקת קבצים לשרת ( אצלי יש AV רשתי )

אני מאמין גדול בשרתי קבצים ביתיים , אני מאמין שהם מקלים את העבודה,  לטווח ארוך חוסכים באמצעי אכסון ומשאבים - שכן אין צוך שלכל מחשב בבית ( ולי יש 8 פעילים ) יהיה  דיסק קשיח מפוצץ , אלא מספיק שיהיה משהו כמו 80GB למשתמש ממוצע ( אני לא ממוצע כנראה ) ושיהיה שרת קבצים עם רוב האכסון עליו , כך ניתן להגדיר לכל משתמש נפח משלו , או נפח אכסון כללי לכולם , אצלי למשל הMy Documents בסביבת הWindows הוא בעצם Mount לכונן רשתי מתאים.

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

בהצלחה.

Labels: access, architecture, design, guide, linux, script, service, software, solution

Posted by barry at 9:26 PM | Link | Comments

כחלק ממחקר שביצעתי בשבועות האחרונים בנוגע לזליגת מידע דרך מערכות כגון 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 ). לפי דעתי האמיתית אין זה פתרון מושלם או הרמטי , אך הוא זול ומהיר ליישום ובכל סדר גודל של ארגון , ולכן שווה ליישום לכל ארגון.

Labels: access, honeypot

Posted by barry at 5:18 PM | Link | Comments

[ how to block logmein - נושא ]

למי שלא מכיר את שירות LOGMEIN , מדובר בשירות מצויין המאפשר גישה פשוטה מרחוק לצורך השתלטות מרחוק על מחשב , ועל ידי התקנת תוכנת קצה קלת משקל. התוכנה לאח מכן פותחת בעצמה פורט 443 אשר פתוח אצל כולנו בFW , ואז בעצם יוצרת קשר מוצפן עם האתר של LOGMEIN.COM .
לאחר מכן , המשתמש יכול לגשת לאותו אתר LOGMEIN.COM ולהכניס את המשתמש והסיסמה , ובעצם להשלים קישור בינו לבין מחשב המרוחק. יתרה מכך , לשירות LOGMEIN יש תוספת שנקראת LOGMEIN-BACKUP אשר מאפשר גיבוי נתונים מרחוק , כלומר המחשב בארגון עלול לשפוך מידע החוצה לשרת או אתר חיצוני , אותו שרת יעביר מידע הלאה והלאה , והנה יש לכם זליגת מידע לפי הספר.

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

אגב , שירות LOGMEIN משתמש בשיטת CIPHER BLOCK CHAINING - CBC , בכדי לאפשר לשירות לעבוד בתצורה קרובה לSTREAMING ככל האפשר תוך שמירה על הצפנה - או במילים אחרות - ממש כמו כן שירות VPN שאנחנו מכירים - ולכן אכן מדובר בפתיחת ערוץ VPN מוצפן לארגון ללא רשות או הסכמה של מדיניות אבטחת המידע והגורם האמון עליה.

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

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

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

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

ניתן ומומלץ גם לחסום את הFQDN המתאים של חברת LOGMEIN - שהוא - secure.logmein.com
כך בעצם שינוי כתובות יחסם גם כן ( לא להקטין ראש , לחסום בשתי הדרכים ) למעשה גם אותו ACTIVEX אשר מדבר עם LOGMEIN יושב תחת הכתובת הזו , ולכן חשוב לחסום

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

עכשיו ברמה אפליקטיבית
במידה ובארגון מוטמעת מערכת בקרת אפליקציה על תחנות הקצה והשרתים , כמו למשל מערכת Cisco CSA או Integrity של Checkpoint , ואפילו בתצורה קצת פחות מכוונת אבטחה - Microsoft GPO - ניתן ליצור הגנה חלקית על המערכת על ידי בדיקת קיום הקבצים הבאים :

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

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

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

חשוב לציין שישנן חברות אשר הטמיעו אלמנט חסימה כבר במערכות האבטחה הקיימות שלהן , לדוגמא , חברת CHECKPOINT הטמיעה חתימה במערכת הSmartDefense שלה , שהוא חלק מפתרון הUTM-1 , אשר מאפשר לחסום בדיוק בשיטה שציינתי את LOGMEIN , ללא צורך בהגדרות מסובכות - אלא רק סימון V ( לינק לעמוד בצ'קפוינט - כאן ) הפתרון קיים אצלם החלק מהעדכון שבוצע למערכות מנויים בסוף אפריל 2007 , כך שלמי שיש שירות עדכוני תוכנה פעיל על הFW - ההגנה קיימת - רק להפעיל.

Labels: access, hazard, software, thesis, vulnerability

Posted by barry at 2:05 PM | Link | Comments

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

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

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

הפתרון המוכר ביותר לגישה מוצפנת ( ולכן לא אדבר כאן על PPTP ועל יישומים שלו למרות שחלקם אף כוללים הצפנה ) יהיה להשתמש בפרוטוקול אשר יעטוף את התצורה הרגילה לגישה בפרוטוקול מוצפן ( למשל RDP OVER SSH ) ובכך יאפשר גישה בטוחה. הדרך המוכרת ביותר לבצע זאת היא על ידי IPSec , הצפנת התווך בין שתי נקודות או בין נקודה לרשת.

בשנים האחרונות אנו רואים מספר אלמנטים של שימוש בSSL לצורך הקמת אותו תווך מוצפן, מדובר למעשה בשימוש בSSLv3 ( שהוא בעצם TLS המוגדר בRFC2246 ). למי שלא מכיר - SSL עובד בשכבת הSESSION והומצא על ידי NETSCAPE לפני מספר שנים שלא זכור לי לנקודה זו. ובכן המטרה בשכבת הSESSION הייתה לאפשר לעבוד עם SESSION COOKIES בדפדפנים ( שכן פרוטוקול HTTP אינו תומך בSESSION כלל ) . ובכן , על מנת לאפשר לאפליקציות רשתיות לרוץ על התשתית המוצפנת , עלינו לרדת כמובן שכבה, לכן הומצא הTLS שהוא Transport Layer Security שמאפשר לנו להצפין בשכבה הרביעית .

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

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

מובן שלכל פתרון יש היתרונות והחסרונות שלו , ומאוד תלוי איך אותו VENDOR בוחר ליישם את פתרון הSSL-VPN שלו. מנסיוני אין פתרון אחד שמתאים לכל ארגון , בסביבות מונחות יצרן אחד ספציפי יתכן שיתאים פיתרון אחד , בעוד לארגון אחר אשר דורש ניקוי בAV לתשתית הSSL שלו יתאים פתרון אחר. ישנם פתרונות המהווים PROXY מלא בין נקודת הגישה לאתר עצמו, ישנם פתרונות אשר מסוגלים לבצע בדיקות UTM וניקוי של מזיקים מהתווך המוצפן, וישנם אף פתרונות שמקימים סביבה נפרדת חד פעמית מוצפנת אשר אינה יושבת על הIO אלא בSANDBOX ייעודי. אין כאן כללים מנחים ויש לשקול כל פתרון לגופו.

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


** שימו לב , ישנו המשך שעיקרו טכני בתגובות למאמר זה.

Labels: access, ssl, technology, vpn

Posted by barry at 10:10 AM | Link | Comments