Confessions Of A Dangerous Mind

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: architecture, desi, design, english, vmware

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

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

הסיבה לבעיה נעוצה בעובדה ש Proxy ( או Load Balancer ), שובר את הTCP Stream ומייצג כתובות IP אחרות בחלק הפנימי שלו . לפי כך מערכות קלאסיות כמו IPS או דומות , אינן רואות את כתובות הIP האמיתיות אשר הגיעו מהעולם. לא ניתן לזהות את מקור ההתקפה בצורה קורלטיבית ומכך נגזר - שאי אפשר להגן בצורה יעילה כנגד התקפה על פי זיהוי מקור.

כאן בדיוק נכנס עולם ניתוח האפליקציה.

כאשר Proxy או כל TCP Terminator כלשהו ( כגון Load Balancer ) קיים , אחת התכונות שלו היא הוספה או עריכה של Headers - דוגמא טובה תהיה בHTTP Header. התוספת הרלוונטית במקרה של Proxy תהיה בצורת פרמטר X-Forwarded-For , אשר הינו פרמטר המכיל את הIP המקורי אשר קולף על ידי הProxy והוחלף בכתובת שלו עצמו.

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

כמובן רצוי לוודא שקיים Trust מסויים בין הProxy לבין אותה מערכת , כדי שהמערכת תדע שהHeader אכן שונה על ידי הProxy ולא על ידי אלמנט צד שלישי ,כגון האקר שרוצה לעקוף IP Filtering בצורה זו.

Labels: design, imperva, technology, waf

Posted by barry at 8:12 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

בתור מי שראה חלק ניכר ממערכות המחשוב ברשתות 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: architecture, design, software, solution

Posted by barry at 9:01 AM | Link | Comments

נראה שאי אפשר עוד להתחמק מהשאלות שהציפו אותי לקוחות וקולגות בתחום שכבת ה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: architecture, design, nac, solution

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

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

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

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

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

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

Labels: consulting, design

Posted by barry at 6:14 PM | Link | Comments