Thursday, March 04, 2010

My New ESXi Lab System

For a while now , i have been thinking about building a Lab Server at home , that will save me time and effort for my day to day dev and other tech stuff. and decided to go with VMWare’s ESXi solution for a virtual environment.

My basic requirements were :

  1. need to run at least 6 resource demanding machines at the same time
  2. need for virtual networking
  3. silence in my lab
  4. performance.

After some spec digging , I finally went for the following spec :

  • Motherboard : Gigabyte GA-X58A-UD3R (link)
  • Memory : Crosair 12GB (6x2GB) DDR3 1333 (link)
  • CPU : Intel i7 920 (link)
  • CPU Cooler : Thremaltake V1-AX CPU Cooler (link)
  • HD : 4x WD Caviar Blue 500GB 7200RPM 16MB WD5000AAKS (link)
  • RAID Controller : Adaptec 2405S (link)
  • Display : Gigabyte HD 4350 512MB GDDR2 DX10.1 HDTV DVI HDMI PCI-E (link)
  • Case : Antec - Nine Hundred Two (link)
  • PSU : Thermaltake ToughPower W0103 600W PFC (link)
  • Additional NIC : Intel PRO/1000 GT Desktop Adapter (link)

Although the Motherboard of my choice includes 3 (!) built in RAID controllers for different raid approaches , i had to introduce a more robust RAID controller that will support my demand for performance ( RAID 10 ) , will offload the CPU cycles to a dedicated processor , and will also be supported by VMWare ESXi , which is not trivial. same reason goes for the additional NIC – the Intel PRO/1000 MT is there in order for the ESXi HSC to have all drivers and hardware in my box officially supported.

Some design decisions :

  • first , i wanted to make sure that the network card is officially supported , because as of now , VMWare only supports specific certified hardware ( an up-to date list of supported hardware can always be found here ) but the problematic ones are always the network controller and the disk controller (which halt the install if the install process doesn't like them). that's why i went with an Intel one, which at the time can be purchased in eBay for around 25-30$.
  • for the disks , i chose 4 x Caviar Blue 500GB disks, and wanted to use them as a RAID 10 array , so all and all i will get 1TB of extremely fast storage, and i chose the Caviar Blue, because unlike the Caviar Green which throttles down to save energy , i need performance – and the Caviar Blue maintains a constant 7200RPM rate.
  • the network card consumed my one and only PCI slot on the Motherboard , so although i was already considering a PCI Express RAID Controller , this became an essential part. at first i thought i could try to use one of the onboard RAID controllers , but VMWare rejected them, which at the end was ok – since by introducing the Ataptec card , all of the CPU cycles that are required to maintain the RAID are offloaded to a dedicated processor on the card. choosing the adaptec was fairly easy , since i wanted 4 disks in RAID 10 and PCI Express , and then i came across this article from Overclock3d.net which was enough to convince me im taking the right approach.
  • for power supply i went as i always do with a Thermaltake Toughpower PSU , which i calculated based on their online PSU calculator , and multiplied by 1.6 as I always do when scaling a PSU.
  • for RAM , just wanted a Triple Channel memory, and as much of it as i can get for a descent price, same as for display – i just had to have a display adapter in , so this was a cheap one with DVI+VGA+HDMI which made sense to have for future screens if i ever need one on this system.
  • for the chasis , i wanted a box that will be cool , good air flow and fanning , and will be easy to build a heavy duty system into. my only complain will be that in order to mount drives , i had to take out the drive bay out ( the bold holders are hidden ) which took some time, but other than that , its an impressive beast. a good review of the box could be found here.

The ESXi latest version at time of install is the 4.0U1 which has more than a handful of features.

I am a happy chap today.

 

not one of my standard posts … but hey , its my blog :)

Barry.

Labels: , , , ,

Friday, December 26, 2008

Google Analytics Cookie Jar

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

אני מקבל לא מעט שאלות לגבי עוגיות מאוד ספציפיות -עוגיות ה utm שמופיעות תמיד כ :

__utma , __utmb , __utmc , __utmv , __utmz

SNAG-0018

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

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

utma

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

utmb + utmc

עוגיות אלו עובדות במשותף בכדי לדגום זמן שהיה באתר - כאשר utmb לוקחת SIMESTAMP של זמן הכניסה , וutmc מקבלת TIMESTAMP של זמן סיום הSESSION , או EXPIRATION. ולמעשה משמשות לשם אותן פונקציות ניתוח.

utmv

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

utmz

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

 

נעבור לסיכונים

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

יש להבין שהמידע בעוגיות אלו יכול להשפיע אם מישהו יבצע TAMPERING או INJECTION על מנגנון הURCHIN של גוגל , ובעצם הנזק הפוטנציאלי הקיים למנגנון ניתוח האתר יכול לעלות לנו בכסף. כי אם למשל אני מזריק לUTMC ערך הגדול ב10 ימים מUTMB , וכמו כן מכניס לUTMZ קישורים לגוגל עם מילות חיפוש לא נכונת .. ואני מבצע זאת על ידי מניפולציה על גבי מספר רב של מחשבים - אפשר פוטנציאלית לפגוע באמינות המידע שאנו מקבלים מהמערכת ולגרום לבעל האתר להשקיע משאבים וכסף במקום לא רלוונטי.

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

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

דרך שניה, על ידי COOKIE SIGNING ניתן לוודא שאכן העוגיה מכילה מה שהSETTER התכוון כאשר בנה אותה , ולא שובשו ערכים ( יעיל יותר מANTI-TAMPERING למיניהם , לפי דעתי ).

 

עוד מידע לגבי מנגנון הGoogle Analytics ניתן לקרוא בספרות הבאה :

Advanced Web Metrics With Google Analytics - Bryan Clifton

Google Analytics 2.0 - Jerri L. Ledford and Mary E. Tyler

Google Analytics Shortcuts - Justin Cutroni

Labels: , , , ,

Tuesday, December 16, 2008

Security Assets Interoperability

שלום לכולם,

אתם מוזמנים לקרוא את הפוסט האחרון שלי בבלוג ImperViews בקישור הבא :

http://blog.imperva.com/2008/12/the-interoperability-of-your-s.html

Labels: , , ,

Friday, June 27, 2008

אנטי - Agent

ועם כותרת משונה שכזו , נסביר...

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

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

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

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

ומה מניע את עמדתי ?

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

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

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

לעומת זאת , פתרונות הAppliance השונים , נבנים תוך ראיה מסוג שונה --> Throughput.

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

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

Labels: , , , , ,

Thursday, March 13, 2008

פרסום BGP ( או כתובות אחוריות ) לא גורם סיכון לנתב !

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

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

אבל, BGP ... אוי BGP ... ולאו דווקא בגלל שהוא BGP ...

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

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

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

אני רוצה להציג בפניכם שרטוטון :

BGPATTACK

עכשיו :

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

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

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

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

בכל אופן , הכתוב פה הוא דעתי.

Labels: , ,

Monday, February 11, 2008

הגבלה במקום חסימה ,P2P ברשת הארגונית.

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

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

דעתי הכנה בנושא היא - לא לבצע חסימה , אלא לבצע Shaping לתעבורה זו לניצולת בלתי אפשרית של עד 2K במערכות בקרת הגישה והניתוב.

הסיבה היא טכנית גרידה -

כאשר אפליקצית תקשורת כגון SKYPE מנסה ליצור קשר החוצה עם העולם , היא פונה לאחד ממאות הכתובות שיש בחוץ ופונה אליו בפורטים מסוכמים מראש על מנת לבצע גישה החוצה לשיחה. אך אם אין גישה שכזו בשל PORT חסום או IPS אשר מנסה לשבור את הבניה של התקשורת - התוכנה מתחילה להשתולל ולחפש דרך אחרת לצאת החוצה כדי לתת שירות ( וספציפית Skype מתמחים בCovert Channeling ) למשל על ידי יציאה דרך HTTP וכדומה. ולכן , בעצם ברגע שחסמנו SKYPE - ייתכן ולא באמת חסמנו , אך מה שכן , בטוח גרמנו לרעש ברשת , כי כל מחשב שינסה לגשת יעמיס לנו על הציוד ללא סיבה נראית לעין.

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

Dont Block It , Shape It.

Labels: , , ,

Friday, January 04, 2008

לסרוק ולא לנקות - Online AV Scanners

נשאלתי לאחרונה שאלה מעניינת ונכונה . מדוע כלי AV אשר מופיעים באתרי כל חברות האנטיוירוס - אינם יכולים לנקות וירוסים מהמחשבים אלא רק לסרוק ולאתר אותם ?

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

מדוע לא ניתן לנקות אלא רק לסרוק ?

כאשר אנו עובדים במוד של Remote Service , אין דרך טבעית לאפליקציה לעבוד מול סביבת הI/O של מערכת ההפעלה . זאת בשל הגבלות ההגנה בשכבות של מבנה מע' ההפעלה , ובנוסף הבידוד בין סביבת מערכות הFileSystem מסביבות הActiveX השונות.

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

Labels: , , ,

Thursday, November 29, 2007

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

למי שלא מכיר - מערכת הCA ( ר"ת Certificate Authority ) , היא אותה מערכת אשר מנהלת ומחוללת סרטיפיקטים עבור הארגון , לכל מטרה שהיא - ובעיקר לשם אימות ועבודה מוצפנת מול מערכות שונות. לדוגמא - אחת הדרכים המקובלות כיום לעבוד בתשתית PKI , או להתחבר בVPN , הם באמצעות סרטיפיקט המופק על ידי מערכות הארגון.

בין המערכות שמרכיבות את הCA , תמיד קיים הCRL ( ר"ת Certificate Revocation List ) אשר מולו בעצם מתבצעת הבדיקה - האם הסרטיפיקט קיים וValid , או האם הוא Revoked או פג תוקף מסיבה כלשהי. כמובן שמערכת זו צריכה להיות זמינה לכל הגורמים הרלוונטיים.

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

אחד הדברים החשובים ביותר בארגון שלנו מבחינת תשתית PKI , הוא הPrivate Key שלנו. אותו מפתח מנוהל על גבי שרת הCA. מסיבה זו בדיוק - הופך שרת הCA לאחד הגורמים החשובים ביותר ברשת שלנו ודורש הגנה מקסימלית. שכן ברגע שנגנב הPRIVATE KEY שלנו , אפשר ללכת הביתה ...

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

ראשית , יש ליצור Subordinate CA , בעצם שרת CA משני אשר נגיש מבחינת המערכות השונות , ואז יש לבצע העברה של שרת הMaster CA לסגמנט משל עצמו ! לא VLAN ולא שום אמצעי לוגי -אלא רגל בFW. לאחר מכן יש למקם אכן את הCRL באיזור DMZ , אך אם הסרטיפיקטים הם לשימוש פנימי ארגוני - למקם אותו באיזור הSDMZ ( ר"ת Secured DMZ ) שמשמעותו שזהו חיץ שאינו נגיש מהאינטרנט או לספקים חיצוניים - אך נגיש לכל המשאבים בארגון. בשלב האחרון , יש לכבות את שרת הCA. אין שום סיבה שהוא יהיה נגיש , שכן המפתח הפרטי המוחזק על ידו לא צריך להיות זמין , ותפקודו של הSCA יהיה פונקציונלי לחלוטין , תוך סיכון פחות של משאבי הרשת.

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

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

Labels: , , , ,

Sunday, September 23, 2007

איך להקים שרת קבצים פשוט ובטוח על Linux

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

Sunday, August 26, 2007

ניהול אפליקציה מרכזי

בתור מי שראה חלק ניכר ממערכות המחשוב ברשתות ENT בארץ, הופתעתי לא פעם לגלות שאין פתרון Software Deployment מרכזי אמיתי ללקוחות , פרט לפתרונות הWSUS \ SMS של מיקרוסופט. למרות שאלו פתרונות טובים בנישתם - הם נופלים כאשר מדובר באפליקציות של יצרנים אחרים.

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

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

בעצם על מה אני מדבר - Software Deployment \ Asset Managment \ Patching Services מרכזיים אשר מטרתם כמובן לוודא ולקיים ארגון ולאפשר לו להמשיך להתקיים בגדילה וכמובן לשמר על רמת אבטחת מידע , עדכניות אפליקטיבית , אחידות אפליקטיבית , ולשמר ידע אודות שינוי התנהגותי במבנה אפליקטיבי של ארגון.

המערכות הלו בד"כ עובדות בתצורת שרת POLICY מרכזי , עם PROXIES ( במידת הצורך ) פזורים באתרים מרוחקים.. וכמובן CLIENT על כל תחנה , אשר מהווה גורם הדיווח וההפעלה על ידי השרת. אציין גם בצורה שהיא טיפטיפה BIAS , אחד הפתרונות האהובים עליי בתחום זה ומנסיוני איתו כמובן - BigFix אשר נראה מעולה ומבדיקותיי בסביבות מעבדה - נראה בעל התושיה הרבה הביותר . כאשר בין המדדים יש את גישת הLINUX\UNIX\WINDOWS\MAC ולא רק סביבה אחת כמובן.
אגב - ישנם מוצרים רבים בתחום זה , חלקם אפילו תוצרת כחול לבן ( Prefix ) , וישנם גם פתרונות מוכוונים DATACENTER ( כגון OPSWARE ) .

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

היופי של מערכות כאלו הוא היכולת למשל להחליף מערכות של שרתי AV ( מערכת BIGFIX למשל יכולה לדבר מול אתרי חברות הAV ולדחוף בעצמה את עדכון הDAT האחרון , ודומים לאלה ... ) ולכן ניתן מיידית לחסוך במשאבים מסויימים ( במצב כזה , שימו את החומרה הכי חלשה בארגון לשרת הAV , רק בכדי שיהיה HEARTBEAT ... אני אישית היית שם אותו על VMWARE )

Labels: , , ,

Tuesday, July 24, 2007

NAC לסניפים מרוחקים - ככה עושים את זה

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

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

סתם BRIEF קצר למי שלא מכיר את הפרוטוקול שעליו נדבר - 802.1x - פרוטוקול זה מאפשר בעצם כאחת האפשרויות שלו לבצע הזדהות על מנת לקבל ATTRIBUTE חשוב מאוד , שהוא VLAN . מה הכוונה בעצם - בסביבת 802.1X ( היום כבר כולם מכנים זאת סביבת NAC - Network Admission Control ) כאשר משתמש מתחבר עם כבל למתג הארגוני - הוא אינו מקבל כתובת IP מהרשת הארגונית , או קישוריות לוגית . אלא מקבל כתובת IP זמנית , ומוכנס לתוך VLAN זמני לצורך זיהוי ובדיקת אבטחת מידע, היוזר מגיע לאותה סביבה , יוצר קשר IP עם איזשהו ציוד NAC אשר מריץ עליו בדיקות מרוחקות או מבקש ממנו לבצע בדיקות ( למשל : האם יש לך אנטיוירוס פועל ) ואז לאחר שאומת שהמחשב הוא "נקי" או לחליפין "מותאם לסביבה" המשתמש מקבל בקשת אימות על ידי Certificate או על ידי משתמש וסיסמה. למעשה לאחר שהמשתמש מזין פרטים נכונים , הוא מועבר לVLAN הנכון הארגוני ומקבל IP מDHCP ברשת , ומתחיל לעבוד - התהליך קצר למרות שנשמע ארוך ומסורבל. במידה והמשתמש הזין פרטים לא נכונים , הוא עובר לRESTRICRED VLAN אשר שם בעצם אי אפשר לעשות כלום, אין תחנות עבודה או שרתים וזהבעצם מבוי סתום, אם בדיקת האבטחה בהתחלה נכשלה , מועבר המשתמש לREMIDIATION VLAN שבו יש שרת ניקוי ותאימות ארגונית , אשר בעצם מאפשר למשתמש "להשלים חוסרים" ,למשל אם אין לו AV מותקן - על השרת הזה יהיה הAV הארגוני עם מסך הסבר כיצד להתקין על המחשב המרוחק.

זה היה בקצרה 802.1X ב120 שניות ( כמו שחבר טוב נוהג לומר )

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



אז מה יש לנו כאן בעצם :
רשת MPLS רגילה עם מספר סניפים ( ציירתי אחד לדוגמא ) ועם ציודים סטנדרטיים נדרשים כגון FW וכמובן דבר חשוב שנדרש - מתג שתומך בEAP\TLS אשר מחייב בסביבת 802.1X . חשוב לציין שבכדי שהפתרון יהיה מושלם - כדאי שהמתג יהיה LAYER3 ויתמוך GRE בשביל ליצור סביבה מושלמת.

מה עושים בעצם -
מקימים סניף לוגי כלשהו ברשת ( אני תמיד ממליץ להשים סביבה כזו בחוות שרתים של אותה ספקית תקשורת ( מאחר והקישור לשם יהיה האמין והיציב ביותר , ולא יחייב קישוריות יקרה לצורך הזדהות \ מה גם שUPTIME הוא סופר קריטי בסביבה כזו ) הסניף הלוגי הזה יכיל בתוכו שני מוצרים בדרך כלל , (לעתים גם LDAP) שהם יהיו בעצם אותו שרת REMIDIATION שתיארתי קודם לכן , וכמובן מכונת הNAC שלנו שבעצם מתפקדת כשרת RADIUS לכל דבר ( אני אישית מאמין אדוק בפתרון של JUNIPER לנושא , למרות שאפשר אפילו להתקיים מIAS פשוט ).

החלק החשוב ביותר הוא להקים GRE TUNNEL מוצפן בין שרת הNAC בסניף הלוגי , לבין כל מתג שקיים בסביבה . זאת מאחר ואנו רוצים שתהליך ההזדהות יעבור בלי הפרעה בתוך מסלול יעודי שלו עד למערכת האימות, GRE נותן לנו בדיוק את זה , כי אפשר לבקש מהציודים בדרך לא לבצע בדיקות על PACKET אשר מסומן עם GRE HEADER וזה חשוב לנו לצורך ביצועים ברשתות בעלות מאות סניפים...

מה שקורה בעצם בתהליך הוא שהמשתמש מתחבר למתג ( נייד נייח או WIFI הינם אותו דבר בסביבה שכזו ) והמתג נותן את הDEFAULT VLAN שלו שהוא - VLAN ההזדהות , המשתמש יקבל DHCP משרת DHCP שנמצא ברשת ( חכם מאוד עבור הVLAN הזה לקיים מחשב DHCP באותו סניף לוגי , רק למטרה זו ) ואז יש לנו תקשורת עד הNAC שלנו , המשתמש עובר בדיקות ואז צריך להכניס פרטים מזהים , אם הכניס פרטים נכונים , הNAC יעביר חזרה את הפרטים למשתמש ולמתג , המתג ישלח שאילתת RADIUS לאימות פרטים מול הNAC - ויאומת , והמתג יחליף בהתאמה את הVLAN TAG לVLAN הנכון , ולאחר מכן המשתמש יקבל DHCP מחדש מהנתב או השירות המקומי הסניפי שלו.

כמובן שצריך ליצור GRE נוסף שמאפשר הגעה לVLAN REMIDIATION למקרה שבו המשתמש צריך לבצע פעולות התאמה לפני שהוא יכול להתחבר לרשת. חשוב מאוד שלאותו NAC תהיה רגל בכל VLAN כדי שיוכל תמיד לענות לבקשות אימות וביצוע בדיקות הזדהות ואמינות מכל מקום.

אני תמיד ממליץ אגב להקים את הסביבה של הסניף הלוגי בשרידות , כלומר או ב2 חוות שרתים , או במצב CLUSTER באותה חווה , מאחר ובתצורה סטנדרטית , אם אין קשר לNAC או שהוא למטה - המשתמשים כולם מתנתקים מהרשת כמובן. ( אגב יש פתרון מיוחד שאומר שאם אין קשר לNAC אז צריך לבצע FAILOPEN ולהכניס אוטומטית לVLAN הארגוני , אבל אני לא שלם עם פתרון כזה )

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

Labels: , , ,

Saturday, April 28, 2007

פתרונות חיפוש לעסקים - Google


ובכן , החברה האהובה עליי Google - עושה את זה שוב. [ האזכורים הראשונים למערכת זו הראו לי לפני כשנה וחצי או שנתיים ... אבל לא זכור לי שפורסם באתר של גוגל באופן רשמי ] , אבל אם תיכנסו ל
לינק הזה תוכלו לראות את אחד הפיתוחים היותר מעניינים של גוגל לעולם הLarge Scale Enterprise ולעולם מנועי חיפוש הנתונים וfריית הנתונים העסקיים.

למעשה מה שעשו גוגל ( אגב , Yahoo + IBM וחברות אחרות מפתחים פתרונות מקבילים , וכמו כן יש פתרונות מבית Microsoft אשר זו מטרתם גם כן וכמובן מנוע X1 המושלם מכל בחינה , אבל אני איש של גוגל ... מה לעשות ) הוא לקחת את המנוע האדיר שהם פיתחו , וליצור מערכות INDEXING למידע ארגוני , אשר כל משתמש יכול לרכוש ולנטוע מערכת חיפוש מתקדמת ביותר , בארגון שלו , באתר שלו , או עבור לקוחות שלו. והיתרונות בולטים , מכונת הGOOGLE MINI יכולה ברישוי הכי זול שלה ( 1995$ ) לחפש ולבצע INDEXING למעל 50,000 מסמכים - כלומר זהו פתרון זול וסביר לכל ארגון אשר מעוניין במנגנון לניתוב , סינון פילטור ויצירת מאגר נתונים על סמך מסמכים. והפתרון האולטימטיבי לשילוב בתוך אתר אינטרנט או אינטראנט ארגוני.

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

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

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

אהבתי.

למי שפספס - הנה שוב הלינק אני מציע לשוטט שם קצת.

Labels: , ,

Wednesday, March 28, 2007

802.1x - אנדרלמוסיה בHIGH-END

אני שמח לבשר שהיום בצהריים סיימתי סוף כל סוף לבחון את כל פתרונות הNAC שרציתי.
וכשאני מתכוון NAC - אני מתכוון לאימפלמנטציה של 802.1x עבור DYNAMIC VLAN עם 802.1q וקביעת החלטת VLAN על סמך מדיניות אבטחה. אחרי הרבה מאוד מעבדות , והקמת תרחישים ותצורות שונות אני עצוב לבשר שאין עדיין סטנדרט למימוש NAC עם CLIENT SECURITY או לצורך העניין NAC עם HOST POLICY ENFORCEMENT בצורה סבירה.

ובכן הפתרונות שבדקתי היו
CISCO - שהיו בהחלט חוד החנית מבחינה טכנולוגית ובהחלט בעלי פתרון קרוב למושלם
JUNIPER - עם פתרון הUAC האיכותי המתבסס על טכנולוגיית הODYSSEY
CHECKPOINT - עם פתרון הINTEGRITY האיכותי שלהם המשלב טכנולוגיה של ZONELABS עם פתרון מנוהל וRADIUS PROXY עבור NAC.
FORTINET - עם פתרון שעדיין לא מכוון לתצורת הNAC אבל בהחלט מהווה CLIENT SECURITY AGENT חשוב מאוד ונותן הרבה משמעויות.
היו גם MCAFEE עם פתרון מאוד יעיל , אבל לא נפוץ בארץ ולכן לא יצא לי לבדוק אותם כפי שרציתי ולקבל גם סיפורי לקוח.

לצערי , לא היה אף פתרון שדומה לפתרון אחר . אם מצאתי יתרונות בHOST CHECKER המעולה של ג'וניפר , הם נפלו על חוסר בPERSONAL ENFOREMENT עבור מדיניות , לעומת צ'קפוינט שנתנו FIGHT מעולה בEND-POINT אבלקצת נופלים מבחינת היכולת שלהם כNAC. ועל פורטינט אין מה לדבר , נכון לעכשיו הפתרון שלהם לא קרוב למציאות , יש להם CLIENT SECURITY מעולה , שעובר בצורה רוחבית את רוב המתחרים ( לפחות מי שבדקתי ) אבל לא מראים יכולות NAC כלשהן כלל.

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

בכל מקרה , בכל הנוגע לEND-POINT SECURITY CLIENT הגעתי למסקנה שINTEGRITY של צ'קפוינט מהווה פתרון כמעט מושלם נכון לעכשיו , במיוחד לאחר הרכישה של POINTSEC ושל REFLEX MAGNETICS אשר לדעתי ישתלבו מהר מאוד במוצר ויהפכו אותה לנקודת האכיפה שאין להתעלם ממנה.

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

בשילוב - אם כל התשתית היא סיסקו - אז אין לאן לברוח - הפתרון של סיסקו הוא המלא ביותר , כי רק הם רואים היום את השילוב של הCSA יחד עם הNAC תוך חתירה להפעלת אלמנטים כגון מניעת זליגת מידע ( הCLIENT מאפשר למשל לחסום COPY\PASTE בין תוכנות שונות ומאפשר לבנות מעטפת REASONABLE USE עבור המשתמש ).

נראה לאן הדברים יובילו אותנו... מעניין לראות מה יביא רבעון 2 של 2007 בתחום הNAC
אין לי ספק שכמו ששנת 2005-6 היו שנות ההתעוררות של הUTM , הBUZZWORD החדש יהיה עכשיו NAC , מה שבתקווה יעיר מחדש גם נושאים כמו PKI וכדומה.

Labels: ,

Monday, December 11, 2006

הזדהות חזקה Out Of Band

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

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

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

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

ובכן , החבר'ה בSECCES לקחו את העולם זה שנים קדימה . הרעיון הוא כזה ... הזדהות מחוץ למחשב. כן כן , לא להשתמש בTOKEN או בסיסמה או באלמנט דומה , תוך שמירה על עקרונות הOTP
( One Time Password - לאחר שימוש אחד לא ניתן להשתמש בסיסמה ). מה שהם עשו זה בעצם לבנות פרופילים של הזדהות לכל משתמש במערכת. למשל אני : יש לי טלפון נייד , יש לי כתובת אימייל , יש לי שלוחה במשרד ועוד כל מיני דוגמאות ... נניח שהטלפון הנייד הוא אימות 1 ,והשלוחה שלי היא אימות 2. במידה ואני צריך להזדהות באמצעות מערכת SECCES, מה שאני צריך לעשות זה להכנס שם משתמש ובקשת אימות . לצורך הענין המערכת הח מוגדרת לCHALLENGE אוטומטי ( מלא אפשרויות קונפיגורציה ), המערכת מחליטה לעבוד איתי באימות 1. מייד אני מקבל SMS שבו כתוב "סיסמתך החד פעמית היא : XXXXXX" , פעם אחרת המערכת בוחרת באימות מסוג 2 , ואני מקבל טלפון שאומר לי "סיסמתך החד פעמית היא : YYYYYY" . פשוט מדהים.

כל תהליך ההזדהות מתבצע OUT OF BAND , כי הרי ידוע שהטלפון שלי הוא שלי , והשלוחה שלי היא שלי , וכל מיני נתונים סטטיסטיים .. בעצם לא צריך רכיב חומרה ( פרט למערכת עצמה ) בכדי לבצע הזדהות. תחשבו על כל הסוכנים בשטח , בלדרים , אנשי מכירות ואנשי תשתיות אשר יכולים להתחבר בצורה חזקה לארגון , מבלי לעלות עשרות דולרים לכל משתמש עבור רכיב שפג תוקף כל 3-4 שנים.

המערכת תוכננה לעבודה כרדיוס ( וככזאת - יכולה להתממשק לכל מערכת שיודעת לדבר מול רדיוס ), יש לה 2 אלמנטים : מערכת האימות ושרת הRADIUS RELAY.
המערכת בנויה בצורה מאוד מוקשחת וSUPER SECURE. בעצם השרת מולו מבצעים את שאילתת הרדיוס הוא קופסא טיפשה אשר רק יודעת לקבל בקשות, השרת החכם הוא שרת האימות והוא מבקש ממנה את הבקשות וגם שם בה תשובות , כלומר אם שמים אותה בDMZ , למכונת הRADIUS RELAY אין כלל צורך בחוקי גישה ממנה החוצה. חשוב לציין ששירותי ההתקשרות, כולל SMS או כל דרך אחרת תלויים בקיום של מערכות כאלה בארגון , או אצל ספק שירות.

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

האתר של SECCES הוא :
www.secces.com

Labels: , , ,

Saturday, December 09, 2006

הבטחה לאבטחה - eCommerce

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

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

אז ראשית קצת טכני, SSL הוא אכן פרוטוקול הצפנה יעיל. הוא מאפשר החלפת מפתחות בין שני
צדדים שהם Client\Server ועל ידי יצירת Session וירטואלי ( מאחר ובHTTP1.0 או ב1.1 לא קיים אלמנט הSESSION ) לערבל ולהצפין את המידע העובר בין הCLIENT לSERVER ולהיפך, ועל ידי כך למעשה ליצור טרנזאקציה בטוחה.

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

הבעיה היא ...
95% מהאתרים בארץ ובעולם אשר מבצעים טרנזאקציות של מידע שמור ואישי , כולל אתרי מסחר אלקטרוני , בנקים , שירותים פרטיים וכדומה , אינם מצפינים את החלפת שם המשתמש והסיסמה.
מה שנוצר בתהליך זה הוא שלמרות שאת המידע הרגיש שלי אי אפשר לגנוב On-The-Fly על ידי
Sniffing או Hijacking ( יש לי סייגים פה ) אבל ניתן לגנוב את שם המשתמש והסיסמה שלי שמשודרים PLAINTEXT עוד לפני שהעברתי פרט אחד !!! אם לאותו CRACKER יש את השם משתמש והסיסמה שלי , הוא לא צריך לחפש את האשראי שלי , כי הפרטים כבר מולו !!!.

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

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


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

Labels: , , ,


About

    My Name is Barry Shteiman, im a devoted tech junkie, and this is my blog.
    E: barry.shteiman -at- gmail.com
    Twitter : bshteiman

Tags & Categories

Mailing List & RSS

Stay Updated  
Add to Technorati Favorites