יום שלישי, נובמבר 17, 2015

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

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

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

הגישה הפשוטה ביותרת אומרת אבטח את הצירים, אבטח את השירות והחזק אבטחה טובה בתוך המתחם שלך.

אבטחת הציר עצמו:

דוגמה קלאסית היא שימוש בצירי ipsec בין השרתים שמתקשרים על קו אינטרנט רגיל -

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

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

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

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

אבטחת תוכן הציר:

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



אחד הפתרונות הטובים ביותר שראיתי לביצוע AAA הוא freeradius (סורי שאני עושה פה פרסומת) , זה יציב זה פשוט עובד והרבה מאוד שירותים עובדים איתו בלי שום בעייה (משרת ה apache ועד שרת הSIP).

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

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

שירותי ה DNS שלך צריכים לספק DNSSEC.
שירות המייל צריכים לדרוש הצפנה תמיד (לא רק כלפי הלקוח אלא כלפי כל שרת אחר ב exim4 זה tls_advertise_hosts), שירות ההודעות המיידיות גם הוא צריך להיות מוצפן בתוך הרשת וכמובן ששרת ה STUN ושרת הקבצים לא צריך להיות מחוץ לרשת האירגונית. כידוע לי גוגל וחברות אחרות עובדות בשיטה זו.
גם ה S2S של שירות ה SIMPLE/XMPP שלכם צריך להיות מוצפן בין השרתים.

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

השירות עצמו שאתה מחזיק חייב להיות מאובטח (אם יש לך sqli בתוך שרת הווב לא עשית כלום).

אין תגובות:

הוסף רשומת תגובה