תהליכי סריקה במבדקי חוסן\חדירה

שלום חברים.

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

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

• חשיפת כתובות רשת של מערכות מרושתות, חומות אש, נתבים וכו' ...
• זיהוי טופולוגית רשת המטרה.
• יצירת מפה לוגית של הרשת תנחה אותנו איך לפעול בשלבים הבאים ותעניק אפקטיביות בכל הקשור לסדר וארגון הממצאים.
• זיהוי סוג מערכת ההפעלה במערכת שנחשפה.
• ממצאים אלה ינחו אותנו בהמשך (לרבות ניצול הפגיעות – Exploitation) .
•  חשיפת פורטים\שירותי רשת פתוחים.
• נרצה ליצור רשימה של פורטים פתוחים (או "מקשיבים"), שכן כל פורט פתוח מהווה דלת כניסה פוטנציאלי למערכת.
• באופן ברור, התקשורת מתבצעת בפרוטוקול TCP ו\או UDP.
• בנוסף לחשיפת פורטים פתוחים, נרצה לדעת איזה שירות רשת נשען על הפורט ומהי גרסתו ברמת ה-Application (כגון HTTP version, SSH version, SMTP version וכו).
•  זיהוי פוטנציאל פגיעות במערכות המטרה.

כדי להגיע למטרה המרכזית בתהליך הסריקה, מתבצעים כמה סוגים של סריקות:

Network Sweeping – סריקה זו מזהה כתובות רשת בשימוש ע"י שליחת פאקטות לכל כתובות הרשת. אם קיבלנו תשובה חזרה – סביר להניח כי קיימת מערכת העושה שימוש באותה כתובת הרשת.

Network Tracing – סריקה זו נגזרת מסריקת Network Sweeping. בעזרתה ניתן למפות את הרשת ולזהות טופולוגיה.

Port Scanning – סריקה זו כשמה היא – חושפת פורטים פתוחים; פורט פתוח הינו שירות רשת ש"מקשיב" לבקשות רשת שונות. אם שירות רשת כזה או אחר פגיע – כאן בד"כ מתחיל השביל ללב המטרה :) .

OS Fingerprinting – לכל מערכת הפעלה - "ההתנהגות" שלה בסביבת הרשת. הווה אומר כי ע"י יצירת פאקטה ספציפית יכולה ללמד אותנו על המערכת עמה אנו מתקשרים וזאת ע"י אופן ה-Response שאנו מקבלים. זיהוי (גרסת) מערכת הפעלה מרחוק באמצעות טכניקה זאת – מכונה "Active OS Fingerprinting". חרף זאת, ישנה אפשרות לזהות את סוג מערכת ההפעלה באמצעות רחרוח (Sniffing) – ללא שליחת פאקטות כלשהן; טכניקה זו הינה פאסיבית.

Version Scanning – באופן ברור, הבודק אמור לדעת אילו שירותי רשת פועלים ובאילו יציאות (Ports). נכון, רוב השירותים פועלים בפורטים ידועים (Well-known ports) אך מנהלי רשת רבים משנים את יציאות ברירת המחדל. בעת יצירת אינטראקציה עם יציאות אלו באמצעות ה-Version scan, נוכל ללמוד על מאפייני הפורט ולדעת באיזו "שפה" הוא מדבר – קרי מהו הפרוטוקול.

Vulnerability Scanning – בסוג סריקה זה, אנו בודקים בד"כ אלפי פגיעויות (Vulnerabilities) פוטנציאליות כנגד המטרה. פגיעויות יכולות להיווצר כתוצאה מהגדרה לקויה או מתוכנה\שירות לא מעודכנים.

מוסכמות בדבר סדר תהליך הסריקה

הרשו לי לתאר בקצרה את זרימת תהליך הסריקה: תחילה, אנחנו מבצעים Network sweeping ע"מ לזהות (כתובת רשת פרטית\ציבורית) מטרות פוטנציאליות. לאחר מכן ננסה לזהות את ארכיטקטורת הרשת, כלומר איך המטרות מקושרות זו עם זו. אח"כ, נבצע Port scanning ע"מ לגלות פורטים פתוחים ("דלתות" למטרה). לאחר מכן, נבצע OS fingerprinting ע"מ לזהות את סוג מערכות המטרה. אח"כ ננסה לגלות את גרסאות השירותים והפרוטוקולים אשר משמשים אותם. לבסוף – לאחר שליקטנו את הנתונים החיוניים – נוכל לבצע Vulnerability scan ע"מ לנסות לחשוף פגיעויות.
חשוב לי לציין שהסדר הנ"ל אינו פורמאלי, אף כי הוא מאוד נפוץ. ישנם בודקים שידלגו על צעד כזה או אחר בהתאם להיקף הבדיקה.

גישות מקובלות

בעת ביצוע המבדק, השתדלו לסרוק מערכות באמצעות כתובת הרשת שלהן – ולא באמצעות שמן.

• לדוגמה, יש לסרוק מטרה כלשהי ע"פ כתובתה ולא שם המערכת. כלומר, 192.168.10.10 ולא mycompany.local .
• אם בכל זאת תשתמשו בשם המערכת לצורך סריקה, סביר כי התוצאות תיפגענה. טכניקות DNS כגון Round-robin עשויות להפריע לתהליך הסריקה.
• לעומת זאת, אם עסקינן באפליקציות ווב (או אתרי אינטרנט) – סביר כי תצטרכו להשתמש בכתובת הדומיין וזאת מטעמי מאפייני פרוטוקול ה-HTTP העושה שימוש ב-Host header.

סריקות "כבדות"

• לעתים לא רחוקות, בודקים יצטרכו להתמודד עם סריקות "גדולות", "כבדות". בואו נעשה קצת חשבון ע"מ לאמוד את הסוגיה:
• בהינתן הוראה לסריקת 1,000 מערכות לרבות כל יציאותיהן (פורטים)
• 65,536 פורטים מסוג TCP ו-65,536 פורטים מסוג UDP (כולל 0)
• בהינתן הנחה גסה כי כל פורט יגזול שנייה אחת, זמן הסריקה יהיה:
• 65,536×2×1,000=131,072,000 [שניות]≈4.15 [שנים]
• אפילו אם נסרוק 100 פורטים בו-זמנית – עדיין ייקח לנו שבועיים (15 יום, ליתר דיוק) להשלים את הסריקה.
• ומה אם ר"ל נדרש לסרוק 10,000 מערכות? 100,000 מערכות?

גישה א' – הגבלת היקף הסריקה

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

• יש לבחור "דוגמיות" מהמטרות;
• בחירת מערכות "מייצגות", הווה אומר – מערכות מרכזיות שמפעילות שירותים בסיסיים.
• נשים דגש על פורטים "מעניינים" כגון 21, 22, 23, 25, 80, 135, 443 וכו'...
• החיסרון: איך נקבע אילו מערכות הינן מייצגות? מה עם פורטים אחרים?

גישה ב' – סקירת חומות אש
גישה נוספת הנותנת פתרון לחסרונות גישה א' היא סקירת חוקי חומת האש (firewall rule set) ברשת ולהגדיר את הסריקה בהתאם לחוקי החומה.

• נבחר פורטים שסביר כי יעברו את סנן החומה.
• גישה זו ניחנת באפקטיביות רבה לגבי סריקות כבדות.
• חסרון: בד"כ הגישה הנ"ל לא מתאימה לבדיקות מסוג "Black box".

גישה ג' – האצת קצב הסריקה
במקום להגביל את היקף הסריקה, אפשרות נוספת היא לנסות ולהאיץ את קצב הסריקה.

• יש לבצע "טריק" קטן בחוקי חומת האש:
• נגדיר כי חומת האש תשיב קריאות RESET ו – ICMP port unreachable לפורטים סגורים.
• באופן אישי, אני לא ממליץ לפעול ע"פ הגישה הזאת. 

גישה ד' – האצת קצב הסריקה (2)

גישה זו עושה שימוש בשיטות סריקה מהירות (Hyper-fast):

• קצב שליחת פאקטות מואצת והנמכת זמן ה-Timeout.
• סט כלים מצוין לגישה זו הוא ScanRand של דן קמינסקי.
• תוכנה אחת שולחת Syn-ים והאחרת מרחרחת (sniffing) לתגובת syn-ack.
• חסרון עיקרי: אפשרות גבוהה כי תגרמו ל-DoS (Denial of service)
• לכן, כדאי להיזהר מאוד בסביבות ה-production.

Network Tracing

ע"מ להבין את "הדרך" בה פאקטה עוברת ברשת, נרצה לבצע network tracing. כדי להבין איך ה-tracing פועל, נצטרך לנתח כמה שדות של ה- IP packet header.  

להלן ה-header של פרוטוקול ה-IP בגרסה 4 (IPv4):

IP Header

ובכן, 3 שדות מעניינים אותנו : "זמן חיים" (TTL), כתובת ה-IP של המען וכתובת ה-IP של הנמען – בעזרת שדות אלו נוכל לקבוע באופן דיי כללי את טופולוגית הרשת.

כתובת ה-IP של המען (Source IP Address) הינה שדה של 32 סיביות המייצג את כתובת מקור שליחת הפאקטה (בד"כ זו הכתובת של המחשב עמו אתם מבצעים סריקה). כתובת ה-IP של הנמען (Destination IP Address) גם היא מכילה 32 סיביות ומציגה את נמען הפאקטה.

שדה ה-TTL מכיל 8 סיביות ומציג לנו כמה "קפיצות – Hops" הפאקטה יכולה לעשות בדרכה לנמען לפני השמדתה. כאשר נתב מקבל פאקטה, בד"כ הוא מוריד ב-1 את ערך ה-TTL ושולח אותה לנתב הבא (בהתאם לצורך, כמובן). כאשר ערך ה-TTL מתאפס – הנתב "זורק" את הפאקטה מתעבורת הרשת ומחזיר למען הודעה: "TTL Exceeded in transit" (ICMP type 11). 

Traceroute

טכניקת ה-traceroute עושה שימוש בהתנהגות הנתב כתלות בערך ה-TTL ע"מ לזהות נתבים נוספים בין המען למטרה. במערכות Linux ו-Unix, הטכניקה מיושמת ע"י פקודת traceroute ובמערכות Windows ע"י tracert.

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

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

יש נתבים שמוגדרים היטב ו-"יודעים" לא להחזיר תשובת ICMP TTL Exceed. במקרה כזה הפקודה תחזיר לנו פלט עם "*" המציינת כי אין מידע על כתובת הרשת.

מאפייני הטכניקה:

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

כל נתב מפחית את ערך ה-TTL ב-1

פקודת ה-traceroute
הרשו לי להסביר בקצרה על יישום הטכניקה במערכות Linux/Unix בעזרת הפקודה traceroute:

• בברירת המחדל, הפקודה שולחת פאקטות UDP החל מפורט מספר 33434 והלאה (כאשר כל פעם מספר הפורט עולה ב-1).
• Flag-ים שימושיים:

• –f [N] : הגדרת ה-TTL ההתחלתי של הפאקטה הראשונה.
• –g [hostlist] : הגדרת מקור הניתוב (עם 8 hops לכל היותר)
• –I : שימוש ב-ICMP Echo request במקום UDP.
• –T: שימוש ב-TCP SYN במקום UDP (מאוד יעיל!)
• –m [N] : הגדרת מספר קפיצות מקסימלי
• –n : הדפסת כתובות לוגיות ספרתיות במקום שמות.
• –p [port] : הגדרת פורט הנמען.
• –w [N] : הגדרת זמן המתנה לתגובת ICMP (ברירת המחדל הינה 5 שניות).

 בנוסף, קיימים לא מעט שירותי Web המבצעים traceroute למערכות – הן ע"י כתובת ה-IP שלהן והן ע"י ה-Domain. שימו לב כי domain-ים יכולים להתאפיין בכתובת IP שונה מזו שהתכוונתם. שירותי Web לדוגמה:

• www.traceroute.org
• www.tracert.com
• וכו'...

Port Scanning

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

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

TCP, UDP ושכבות הפרוטוקול

סביר להניח כי אם הגעתם עד הלום, אתם מכירים ומבינים את מודל השכבות (OSI) , אך ברצוני לשים דגש על 3 שכבות:

TCP/IP model "VS." OSI model

ניחשתם נכון – שכבת האפליקציה (7), התעבורה (4) והרשת (3).  

אזכיר כי:

• רוב שירותי האינטרנט הם מסוג TCP ו-UDP ומועברים מקצה-לקצה באמצעות פרוטוקול IP.
• לכל פרוטוקול מאפיינים שונים – דבר שינחה את פעולת הסריקה שלנו.
• TCP – פרוטוקול אמין, ידוע כ-Connection oriented, שומר על עקביות הפאקטות ומשחזר פאקטים שלא הגיעו ליעדם.
• UDP – ידוע כ-Connectionless. לא אמין ואין הבטחה שפאקטים יגיעו ליעדם.

 TCP Header

TCP Header

להלן מבנה ה-Header של פרוטוקול TCP; נשים לב כי הוא מכיל שדה מען ושדה נמען (16 סיביות כל אחד) המייצגים את פורט המקור ופורט היעד. בנוסף, קיים שדה עם מספר סידור (Sequence number), בעזרתו הפרוטוקול "עוקב" אחרי סדרה של פאקטות ע"מ לוודא כי כולן הגיעו – ובסדר הנכון.
אני רוצה להתעכב על שדה סופר-חשוב המכיל סיביות בקרה (Control bits) . זהו השדה TCP Flags.


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

סיביות הבקרה בפרוטוקול TCP

קיימים בסה"כ 8 דגלונים כאשר 2 מהם דיי "חדשים" (מוצגים ב-RFC 3168). סיביות הבקרה יכולות ללמד אותנו – הבודקים, על מצב הפורט. כל דיגלון ערכו 0 או 1 (בסופו של דבר, גודל כל דגלון הוא סיבית אחת). אציג בקצרה את 6 הדגלונים המוכרים:

SYN – מלשון Synchronize. כלומר – שליחת בקשה למערכת לסנכרון מספרי הסידור (Sequence number). דיגלון זה משמש בעת יצירת Session ותחילתה של התקשרות.
ACK – מלשון Acknowledgement. דיגלון חשוב. ערכו 1 אם הוא "יודע" על פאקטות שנשלחו קודם לכן (כחלק מסדרה של פאקטות).
RST – מלשון Reset. מודיע למערכת כי יש לאתחל את התקשורת (עקב שגיאה וכו...)
FIN – פיניטו :) . מודיע כי אין יותר נתונים שאמורים להישלח מהמקור.
PSH – סיבית זו מציינת כי אין רצף נתונים ולכן אין להחזיק בפאקטה ולחכות לפאקטות נוספות.
URG – מצביע Urgent מציין כי הנתונים שנשלחו הם בסדר עדיפות עליונה ויש לטפל בהם במהירות.

תחילתה של תקשורת מופלאה – TCP Three-way handshake

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

נגדיר מחשב A כך שהוא נדרש ליצור התקשרות (להתחבר, בלשון לא פורמאלית) עם מחשב B. הפאקטה הראשונה שמחשב A ישלח - יכיל סיבית בקרה מסוג SYN וכן מספר סידור התחלתי (לעתים נקרא Initial Sequence Number או ISN) בגודל 32 סיביות. אציין כי מספרי הסידור הם פסאדו-רנדומליים, כלומר קיימת תבנית מסודרת בעת התקשורת אך המספר הוא אקראי לגמרי. דגל ה-ACK יהיה 0 כיוון שזוהי פאקטה התחלתית שאינה חלק מפאקטות שכבר נשלחו.

איך יגיב מחשב B ? אם פורט היעד פתוח (כלומר המחשב "מאזין" לפורט זה), הוא חייב להחזיר פאקטת תשובה מסוג SYN-ACK (פאקטה שסיביות הבקרה SYN ו-ACK הן 1). פאקטה זו תכיל ISN שמחשב B יוצר. בנוסף ערך ה-ACK בפאקטה זו יכיל את ה-ISN של מחשב A ותעלה את ערכה באחד – ISN(A)+1 , ויציין כי למחשב B ידוע (ACK) על פאקטת SYN שנשלחה ממחשב A.

ע"מ להשלים את "לחיצת היד", מחשב A משיב עם פאקטת ACK שמספר הסידור שלה יהיה ISN(A)+1. ערך ה-ACK ייקבע ל- ISN(B)+1 המעיד כי זהו חלק מפאקטת SYN-ACK .

כעת, שני הצדדים "החליפו ביניהם" מספרי סידור כך שכל פאקטה שנשלחת ממחשב A ל-B תכיל מספר סידור החל מ- ISN(A)+1 , ובאופן דומה כל פאקטה שמחשב B מחזיר תכיל מספר סידור שערכו ההתחלתי יהיה ISN(B)+1. 

אם הסעיף הנ"ל הוא בגדר tl;dr עבורכם, הנה תמונה שתמחיש דבריי:

לחיצת יד משולשת בין לקוח ל-שרת

ע"פ RFC 793 המתאר את פרוטוקול ה-TCP וכל האמור לעיל, נוכל לקבוע את המשפט הבא:

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

המשפט הנ"ל מעניק טכניקה יעילה לזיהוי שירותי רשת (פורטים).

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

קיבלנו תשובה מסוג SYN-ACK, ממש "by the book" . הפורט פתוח!

קיבלנו ריסט (RST). הפורט סגור (או חומת אש חוסמת אותו)

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

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

UDP

UDP הוא פרוטוקול פשוט. הכי פשוט. לא אתעכב עליו הרבה.

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

UDP Header

נבחין כי ב-UDP ארבעה שדות בעלי 16 סיביות כ"א. פורט המקור, פורט היעד, גודל ו-Checksum. 

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

אם קיבלנו תשובה כלשהי מסוג UDP, הפורט פתוח!

הפורט סגור או חסום.

לא קיבלנו תשובה \ הפרוטוקול לא נגיש. למה?

• הפורט סגור.
• חומת אש חוסמת שליחת פאקטות UDP
• חומת אש חוסמת קבלת פאקטות UDP
• הפורט פתוח, אך דורש ארגומנטים מסוימים בשדה ה-DATA ...

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

על חוסן, מבדקים ופריצות

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

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

פגיעות (Vulnerability) – פגיעות הינה גורם בסביבתנו אשר יכול לשמש איום כלשהו לגרימת נזק. הווה אומר כי בית ללא אזעקה – הינו פגיע ואף "קורא" לתוקף (האיום).

סיכון (Risk) – סיכון הוא שילוב האיום והפגיעות לכדי סכנה. לדוגמה, המערכות הנ"ל בעלות סיכון שכן קיימות בהן פגיעויות אשר איום מסוים יכול לנצלן.

ניצול (Exploit) – ניצול הינו אמצעי המשמש את האיום(התוקף) כנגד פגיעות מסוימת ע"מ להסב נזק למטרה. לדוגמה, ניצול יכול להיות כלי המייצר והשולח packets לתוכנה מסוימת לכדי גרימת Buffer overflow.

מבדקים, סריקות, פריצות וסקירות אבטחה

(הוספתי את הסעיף הזה ע"פ בקשה של קורא הבלוג)

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

• פריצה אתית (Ethical Hacking)
• מבדק חדירה (Penetration Testing)
• סריקת פגיעויות (Vulnerabilities Assessment)
• סקירת אבטחה (Security Audit) 

המונחים דלעיל מתארים מה אנשי ה-Pentest עושים על בסיס יומי.


פריצה אתית
המונח "פריצה" או "Hacking" הינו בעל משמעויות רבות. המוסכמות הרווחת לגבי משמעות המונח בקרב אנשי אבטחת המידע מגדירה את המונח כ-תהליך גילוי וחקירה של טכנולוגיה מסוימת וחתירה להבנתה ברמה העמוקה ביותר תוך ניסיון לגרום לאותה טכנולוגיה לפעול למטרות שלא לשמן פותחה.  
למרבה הצער, רוב האנשים כיום חושבים כי Hacking הינו מונח שלילי מיסודו – כלומר פריצה למערכות ממוחשבות (ולחשבונות) ללא הרשאה ובמטרה לגרום נזק ולהשיג רווח כלשהו.
לאחרונה, יותר ויותר החלו להשתמש במונח "פריצה אתית" – Ethical Hacking לתיאור תהליך פריצה למחשבים – אך עם מטרה מרכזית אחרת; מציאת חורי אבטחה כדי שאלו יתוקנו. אין מן הנמנע שתהליך פריצה מסוג זה ייעשה שימוש בטכניקות של האקרים "רעים" – אך בפרספקטיבה יותר מקצועית, עם מטרה יותר רוחבית.
ע"פ וויקיפדיה, פריצה אתית מכונה גם פריצת "כובע לבן" ("White Hat Hacking") המבדילה בין החבר'ה "הרעים" המבצעים פריצת "כובע שחור" ("Black Hat Hacking").


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

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

 באופן רשמי, הגדרה נאותה של המונח "מבדק חדירה" הינה פריצה להשגת המטרות הבאות:

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

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

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

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


במאמר זה, אתייחס למבדק חדירה כפריצה אתית לכל דבר.

סוגי מבדקי חדירה\פריצות אתיות

קיימים כמה סוגים\גישות למבדקי חדירה:

בדיקת שירותי רשת (Network services test)

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

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

בדיקת צד-לקוח ( Client-side test)

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

בדיקת אפליקציות אינטרנטיות (Web application test)

כשמה היא – בדיקה למציאת חורי אבטחה בתוכנות מבוססות web \ אפליקציות אינטרנטיות אשר מאוחסנות\פועלות בסביבת המטרה.

בדיקת אבטחה אלחוטית (Wireless security test)

בדיקה זו שמה לעצמה מטרה למצוא נקודות גישה (Access points) לא מורשות ומציאת חורי אבטחה בנקודות גישה מורשות.

בדיקת הנדסה חברתית (Social Engineering test)

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

בדיקת אבטחה פיזית 

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

מתודולוגיות מבדקי חדירה

בסעיף זה, אציג מתודולוגיות חינמיות\ציבוריות המנחות מבדקי חדירה.

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

אם הנושא מעניין אתכם, אני ממליץ לקרוא את המתודולוגיות – הם בחינם.

לדעתי האישית, 5 המתודולוגיות מן היעילות ביותר כיום הן:

• מדריך הבדיקה של OWASP (Open Web Application Security Project)
• NIST 800-115 של מכון התקינה האמריקאי.
• OSSTMM (Open Source Security Testing Methodology Manual)
• PTES (Penetration Testing Execution Standard)
• PTF (Penetration Testing Framework)

 OWASP Testing Guide 
בניגוד לשאר המתודולוגיות, זאת מתמקדת על אפליקציות אינטרנטיות בלבד. מדריך הבדיקה של OWASP הוא חלק מפרויקטים רבים שהחבר'ה ב-OWASP עושים. הוא מעניק התמקדות מעמיקה יחד עם כלים (חינמיים) מקצועיים נוספים. OWASP הוא ארגון ללא מטרות רווח המורכב מאנשי מקצוע מכל העולם. גם בישראל קיים "סניף" שלהם, עם מפגשים ודיונים בנושא. היתרון המשמעותי ביותר במתודולוגיה זו הוא היכולת לקבוע סכנות עסקיות בהתבסס על הממצאים.
לאחרונה, OWASP הוציאו תקן של ממש – כזה המוודא כי תהליך הבדיקה (המורכב, בלשון המעטה) בוצע והושלם.
בנוסף, הארגון מקטלג את 10 סוגי התקפות המניבות את הסכנות המשמעותיות ביותר כנגד אפליקציות אינטרנטיות, כאשר בראש הרשימה מתוארת הסכנה הגבוהה ביותר (A1 – Injection) .
את המדריך המלא תוכלו למצוא באתר הפרויקט, כאן.

NIST Guideline on Network Security Testing 
מכון התקנים והטכנולוגיה של ארה"ב פרסמו מסמך הנקרא: "Technical guide to IS Testing" אשר מכסה ברמה (גבוהה, אם יורשה לי לציין) את תהליך מבדק החדירה ברשתות מחשבים.
המסמך מציג טכניקות לביצוע, ניתוח ואימות מבדקי חדירה ותוצאותיו.
אספקט חשוב אותו המתודולוגיה מכסה הוא האספקט הניהולי; חברות רבות מכניסות למערך ה-IT שלהם גם את הגישה העסקית-ניהולית ורואות את אותו מערך כחלק בלתי נפרד מניהול החברה באופן כללי. לכן, המסמך של NIST מכיל פרמטרים המערבים את הנהלת החברה.  

את המדריך של NIST תמצאו כאן.


Open Source Security Testing Methodology Manual - OSSTMM 
OSSTMM פותח ע"י פיט הרצוג ומופץ ע"י ISECOM. המתודולוגיה ביסודה חינמית אך גישה לגרסאות מעודכנות יותר דורשות רכישת מנוי באתר ISECOM.
באופן כללי, המתודולוגיה מאוד רוחבית, הווה אומר כי היא מכסה סוגים רבים של מבדקי אבטחה – אבל לא בצורה מעמיקה דיו. בין הנושאים המרכזיים במתודולוגיה תמצאו בין היתר: קביעת היקף הבדיקה, בדיקה פיזית, בדיקה אנושית (הנדסה חברתית), בדיקה אלחוטית ועוד... כל נושא מוצג ומוסבר בשיטת "צעד-אחר-צעד". אחד היתרונות הבולטים ב-OSSTMM הוא שהנ"ל מעניק תבניות מוכנות הן לתהליך הבדיקה והן ליצירת הדוח.
מסמכי המתודולוגיה נמצאים באתר ISECOM.


Penetration Testing Execution Standard - PTES
PTES הינו פרויקט מעניין מאוד; הוא מתאר אילו פעולות נחוצות יש לבצע כדי להגדיר את הבדיקה הרצויה כמבדק חדירה. מטרתו להעניק "קרקע" יציבה לביצוע המבדק ע"י הגדרת תקן, סטנדרט לתהליך. PTES נתמך ע"י המון אנשי מקצוע אשר שוקדים לעדכנו בהתאם לטכנולוגיות העכשוויות. בין סעיפי המתודולוגיה אפשר למצוא ניתוח פגיעויות, ניצולן, מידול איומים ועוד...
לסיכום תיאור המתודולוגיה, אציין כי היא הינה מעמיקה ומהווה מקור מצוין לתיאור תהליך מבדק החדירה.
פירוט מלא של המתודולוגיה\תקן, אפשר למצוא כאן.

Penetration Testing Framework 
אחרון (וחביב) ברשימת המתודולוגיות החינמיות, נמצא PTF. המתודולוגיה מתמקדת על מבדקי חדירה מבוססים שירותי רשת ומציגה באופן מעמיק ובשיטת צעד-אחר-צעד את תהליך מבדק החדירה (כולל קישורים לכלים ותוכנות לביצוע מטלה זו או אחרת).
המתודולוגיה מנחה את הבודק מה צריך לעשות ואיך לעשות בכל שלב בתהליך מבדק החדירה. המתודולוגיה נכתבה ע"י Toggmeister ו- Lee Lawson .
הגרסה העדכנית של PTF נמצאת כאן.

תהליך מבדק החדירה

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

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

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

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

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

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

לאחר גילוי הממצאים, הבודק יצמצם את היקף הבדיקה ויבצעה פעם נוספת ע"מ לאשש את הממצא\ים.

הסכם הרשאה

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

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

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

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

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

על מסמכים, נהלים ומדיניות אבטחת מידע

מהי מדיניות?

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

התעדה

"אם זה לא תועד – זה לא קרה."

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

סוגי מדיניות

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

מה עושה מסמך מסוים למדיניות (או מה התוכן במדיניות)?

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

 

חריגות

מדיניות אבטחה צריכה לקחת בחשבון מקרים ומצבים חריגים; ההחלטה על "מה עושים כאשר צריך לעשות X אך מדיניות האבטחה דורשת Y" – נעשית בתהליך הערכת הסיכונים. ניקח את הדוגמה הקלאסית הבאה: 

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

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

זיהוי מדיניות בארגון

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

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

רמות שונות של מדיניות

מדיניות יכולה להתקיים ברמות שונות בארגון. סביר כי כל עוד אינך נמצא בדרג הניהולי הבכיר של הארגון – סביר כי קיים מישהו מעליך אשר יוצר מדיניות שעלייך ליישם. היררכיית מדיניות נפוצה בארגונים נראית כך:

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

מה בין מדיניות לנהלים

• מדיניות – עונה על.... מי, מה ולמה.
• נהלים – עונה על... איך, איפה ומתי.

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

שלב 1: מי מבצע את הנוהל?	למה?
מנהל הרשת מבצע עדכון לתוכנת האנטי וירוס לכלל המחשבים בארגון.	כיוון שנדרשות הרשאות ניהול מסוימות להתקנת העדכונים בכונני המשתמשים
שלב 2: מהו הנוהל?	למה?
קבצי העדכון נבדקים ונשמרים בתיקייה משותפת. סקריפט המופעל בעת התחברות המשתמש למערכת – מוריד את העדכון, מבצע אותו ולבסוף מאתחל את המחשב. מחשבים שעברו עדכון מסומנים בבסיס נתונים מסוים.	הגנת המערכות מפני ווירוסים ע"י עדכון תוכנת האנטי ווירוס באופן תדיר. אוטומטיזציה של התהליך תהיה יעילה יותר ותפיק רשימה מסודרת של אילו מחשבים עודכנו ואילו לא.
שלב 3: מתי נוהל זה מבוצע?	למה?
נוהל זה מבוצע בתדירות שבועית.	ע"מ להגן על המערכות מפני ווירוסים חדשים, ידוע כי תוכנת האנטי ווירוס שלנו מפיקה עדכונים כל יום ראשון.
שלב 4: (מ)היכן נוהל זה מבוצע?	למה?
נוהל זה מבוצע ממחשבי מנהל הרשת	אין דרישה למיקום ספציפי ע"מ להחל את העדכונים. כל מחשב חייב בעדכון.
הסקת המדיניות	מהי המדיניות?
ע"י התבוננות בשתי העמודות דלעיל, נוכל להסיק מהי המדיניות.	"יש להבטיח כי כל מחשבי הארגון מוגנים מפני ווירוסים ע"י עדכון האנטי ווירוס באופן תדיר. מנהל הרשת בכל מחלקה יבצע את העדכון בתדירות שבועית. תהליך זה יכול להתבצע באופן אוטומטי ובתנאי שיבטיח כי כל מחשב קיבל וביצע את העדכון"

הערכת מדיניות אבטחה קיימות

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

שלב 1: בדוק כי מדיניות אבטחת המידע מכילה את רוב המרכיבים הנפוצים

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

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

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

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

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

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

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

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

נספח: תרגיל בהתרחשות

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

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

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

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

בואו נתחיל בעבודה:
מסמך מדיניות שכזה צריך להכיל דף אחד לכל היותר. זכרו– היו ענייניים.

מדיניות הארגון בדבר שרתים לא מורשים

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

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

פעולות:

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

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

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

עד כאן. חג שמח ובטוח לכולם.

הקשחת מערכות Linux: יסודות.

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

ב-Linux זה לא היה קורה. האמנם?
ובכן, בהשוואה למערכות הפעלה אחרות, אין כל ספק כי Linux הינה מערכת הפעלה מאובטחת יותר יחסית ל-Windows, למשל. כידוע או לא, לב ליבה של ה- Linux מורכב מהגרעין (קרנל – Kernel) ואוסף כלים שמרכיבים בעצם את מערכת ההפעלה – ביחד הם מרכיבים את ה"משטח" עליו רצים תוכנות וכלים. קרנל המערכת מבוסס קוד-פתוח (כמו גם רוב כלי אבטחת המידע הקיימים כיום), מה שמאפשר לחבר'ה כמוני וכמוך לזהות חולשות, להתריע ולתקן. בנוסף, מספר גדול וגדל של תוספי אבטחה ("פיצ'רים") מוטמעים בקרנל ושינויים חיוניים בקוד הקרנל מתבצעים מדי יום. Linux מעניקה יכולת מרשימה על בקרת הגישות (מי "שולט" על מי, אילו משאבים משתמש יכול לגשת ועוד). אז, איפה הסיכונים פה?
כמו שספרה של ג'ניפר טרייג מצהיר: "השטן נמצא בפרטים הקטנים" – כאן התשובה. אבטחת המערכת תלויה באופן רוחבי בתצורת (הגדרות) אלמנטים ברובד המערכתי והאפליקטיבי. Linux והקרנל הינם רכיבים מורכבים מאוד ולעתים קרובות – קשה להגדירם באופן "ידני". אבטחת מידע ב-Linux לעולם לא סטטית. ככל שתשתמשו במערכת – כך רמת אבטחתו תרד; שינוי תפעול של פונקציות מסוימות עלול לחשוף את המערכת לאיומים מצד חולשות חדשות המתגלות מדי יום כנגד תוכנות ושירותי מערכת. אם זה לא מספיק – המון הפצות (Distribution) מגיעות עם תוכנות ותצורות מוגדרות מראש התלויות בידע של המפיץ ובמטרת ההפצה (יש הפצות שמכוונות למשתמשים ביתיים, למנהלי מערכת, חוקרי פשעי מחשב ועוד...).

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

• אם תישאלו להזין סיסמה למשתמש root – תמיד תבחרו בסיסמה חזקה [לינק].
• צרו משתמש בנוסף למשתמש root – והזינו סיסמה שתהיה לכל הפחות – סבירה.
• אם תישאלו במהלך ההתקנה על התקנת חומת אש ואפשרות ל- SELinux - אשרו והתקינו.
• למרות שכיום זהו ברירת מחדל – לאפשר הצפנת סיסמאות (MD5) ו-Shadowing.

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

• משחקים.
• שרתים (או שירותי רשת).
• דימונים (daemons) ושירותים נוספים.
• תוכנות וכלים סטייל "אופיס".
• כלים ותוכנות להדפסה.
• בסיסי נתונים.
• X-Windows (שרת ממשק גרפי) וסוגיו (Gnome/KDE).

מערכת Linux פרודוקטיבית אינה צריכה להכיל ממשק גרפי. X-Windows הינה חבילה ענקית המכילה מספר גדול של רכיבים ולהם היסטוריה של חולשות שהתגלו. בשונה מ-Windows, כל הגדרה במערכת יכולה להיעשות דרך ממשק שורת פקודה ( command line ).
הקפידו להתקין את הגרסה העדכנית ביותר של אותה הפצה, אם התקבל לידיכם גרסה ישנה – אין להתחבר לאינטרנט עד שמתקינים את כל ה-patches וה-fixes הקיימים עת ההתקנה. תקראו לי פרנואיד, אבל באבטחת מידע כמו באבטחת מידע – התזמון הוא פקטור קריטי; אם התקנתם מערכת ישנה, קיים פער של זמן עד השלמת התקנת כל העדכונים וה-patches החיוניים. בזמן זה, עת אתם מחוברים לאינטרנט והמערכת לא מעודכנת – מספיק כי תוקף "יתפוס" אתכם בעת סריקתו כדי לנצל חולשות ידועות.
בנוסף, עת סיום הורדת ההפצה, יש להבטיח את שלמותה; השוואת חתימת ה-MD5 תבטיח כי הקובץ שירד לא שונה, והוא זה שבאמת התכוונו להוריד. אמחיש בקצרה: נניח כי ברצוננו להוריד את קובץ ההתקנה של הפצת Debian, תחילה, אוודה כי אני מוריד את הגרסה העדכנית ביותר המתאימה לארכיטקטורת המעבד שלי ולנפח זיכרון ה-RAM במחשבי (64 ביט לזיכרון בנפח 4GB ומעלה). מאתר ההפצה של Debian, אגיע לכתובת הבאה: http://cdimage.debian.org/debian-cd/current/amd64/iso-cd/ .

לאחר הורדת הקובץ, אכנס ל-MD5SUMS ואבדוק (בעזרת תוכנה כגון WinMD5) או פקודת md5sum בלינוקס אם החתימה של הקובץ תואמת לזו המוצגת ב-MD5SUMS:
[one_half]

אבטחת ה- Boot Loaders
תוקף הנגיש פיזית למערכת שלכם יכול בקלות לעקוף את מנגנוני האבטחה הפנימיים של המערכת (במיוחד בבקרות כניסה של שם משתמש וסיסמא). בנוסף, הוא יכול לבצע אתחול (אם אין הגנה על ה-BIOS) או לשנות את תצורת האתחול של המערכת ואת תהליך ה-init (המגדיר אילו שירותים, פקודות וכלים ירוצו בעת האתחול). תוקפים המסוגלים לאתחל את המערכת יוצרים שתי בעיות גדולות: האחת היא האפשרויות הרבות שמערכת Linux מעניקה לאלו המסוגלים לאתחל אותה. השנייה היא מניעת שירות ע"י אתחול לא רצוי.
רוב הפצות ה-Linux עושות שימוש באחד משני ה-Boot loaders : ה-LILO (Linux loader, פעם היה loader ברירת המחדל של Linux) ו-Grub (החליף את ה-LILO וכיום הוא ברירת המחדל ברוב הפצות ה-Linux). Boot Loaders נטענים אחרי פעולת ה-BIOS של המחשב ומעניקים שליטה על בחירת הקרנל הרצוי ובקרה על ה- Boot images. בעת עדכון קרנל, ה-Boot loader יציג את כל גרסאות הקרנל שהותקנו – כולל אלו שאינם מעודכנים. בכללי, מומלץ שלא יהיו הרבה גרסאות קרנל מותקנות – במיוחד לא גרסאות ישנות. לכן, מומלץ להסיר את אותן גרסאות מרשימת הקרנלים ב-Boot loader
Grub מכילה פיצ'רים רבים יותר מ-LILO, מעודכנת יותר ולכן גם מאובטחת יותר. למרות זאת, ברירת המחדל של Grub היא לאפשר לכולם לאתחל את המערכת במצב Single-user mode או לשנות פרמטרי אתחול שונים. בשונה מ-LILO, Grub יכולה להתמודד עם אירועים מסוג זה ע"י בקרת גישה מבוססת סיסמה (מוצפנת SHA512).

הגנת Grub ע"י סיסמה

1) הזינו את הפקודה הבאה: grub-mkpasswd-pbkdf2 , הזינו סיסמא והעתיקו את הפלט המוצפן.
2) ערכו את הקובץ /etc/grub.d/40_custom וצרו שתי שורות:

Setsuperuser="someUser" set password someUser PASSWORD COPIED

שירותי אתחול, Init וסדר האתחול

אציג בטבלה את שירותי האתחול במערכת (מתאימה ברובה ל-Debian אך גם רוב הפצות ה-Linux עושות שימוש בשירותים דומים)

שירותי אתחול, Init וסדר האתחול

אציג בטבלה את שירותי האתחול במערכת (מתאימה ברובה ל-Debian אך גם רוב הפצות ה-Linux עושות שימוש בשירותים דומים)

שם השירות	תיאור	מומלץ להסיר?
acpid	יישום תקן ACPI להגדרת התקנים וניהול צריכת חשמל	לא
anacron	בדומה ל-cron, רק שההנחה היא כי המחשב לא פועל באופן רצוף – כלומר, משמש מחשבים שלא פועלים 24 שעות ביום ומעניק יכולת בקרה לביצוע משימות הנשלטות ע"י cron בתדירות יומית, שבועית או חודשית.	כן – במחשבים שאינם שרתים.
apmd	דור קודם של יישום ACPI ומותקן בד"כ במחשבים ישנים. אם הותקן acpid – מומלץ להסירו.	כן
auditd	The Linux Audit daemon. אחראי לכתיבת רשומות ביקורת (או הערכה) של המערכת.	לא להסיר. מומלץ להגדירו.
atd		כן
autofs	Automount	כן
crond	שירות cron	לא
cups	פונקציות מדפסת	כן
functions	פונקציות לסקריפטים מבוססי shell-script	לא
gpm	תמיכת עכבר ליישומי טקסט	כן
irda	תמיכה ל-IrDA	כן
isdn	תמיכה ל-ISDN	כן
keytable	מיפוי מקלדת	לא
kudzu	זיהוי חומרה	כן
lpd	שירות lpd למדפסות	כן
netfs	Mount network file systems	כן
nfslock	נעילת שירותי ה-NFS	כן
ntpd	שירות שעון מבוסס רשת	לא
pcmcia	תמיכה ל-PCMCIA	כן
portmap	תמיכה לחיבורי RPC	כן
random	לכידת אירועים אקראיים	לא
rawdevices	הקצאת התקנים	כן
rhnsd	שירות הרשת של Red hat	כן
snmpd	שירות SNMP	כן
sshd	שירות SSH	לא
winbind	תמיכה ל-Samba	כן
xfs	X font server	כן
ypbind	NIS/YP client support	כן

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

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

איך נעשה את זה?
יש לערוך את קובץ /etc/issue.net ו-/etc/issue . הקבצים הנ"ל יוצגו בעת התחברות המשתמש לטרמינל.
תחילה, יש לוודא כי מסך ההתחברות יהיה נקי. הזנת פקודת clear אל תוך קובץ ה-/etc/issue ו-/etc/issue.net – תעשה את העבודה:

root@maor-debian:/home/maor# clear > /etc/issue
root@maor-debian:/home/maor# clear > /etc/issue.net

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

********************************************************************

*                                                                 *

* This system is for the use of authorized users only. Usage of   *

* this system may be monitored and recorded by system personnel.   *

*                                                                 *

* Anyone using this system expressly consents to such monitoring   *

* and is advised that if such monitoring reveals possible         *

* evidence of criminal activity, system personnel may provide the *

* evidence from such monitoring to law enforcement officials.     *

*                                                                 *

********************************************************************

לאחר אימות המשתמש והתחברות למערכת, יוצג ה-/etc/motd (Message Of The Day) . גם הוא קובץ טקסט המאפשר להציג אזהרות, נהלים והנחיות למשתמשים שהתחברו בהצלחה למערכת.
ננעל את הקבצים הנ"ל כך שלא יהיו ניתנים לשינוי:
root@maor-debian:/# chown root:root /etc/issue.net /etc/issue /etc/motd
root@maor-debian:/# chmod 0600 /etc/issue.net /etc/issue /etc/motd

משתמשים וקבוצות
נדבך עיקרי באבטחת מערכות הינו אבטחה של נתוני התחברות (קרי שמות משתמש וסיסמאות). מטרתנו כמובן, היא להבטיח כי רק משתמשים מורשים יהיו מסוגלים להתחבר למערכת וכן למנוע מהתוקף גילוי (וניחוש) סיסמאות חלשות.
לינוקס שומרת נתונים אודות משתמשים וקבוצות ב-3 קבצים: /etc/passwd, /etc/shadow, /etc/group .
/etc/passwd מכיל רשימה של כל משתמשי המערכת ומאפיינם:
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
מבנה רשומה בנוי כדלקמן:
username:password:UID:GID:comments:Home Directory:Shell

הקשחת שירות ה-SSH
כעת, נקשיח את שרת ה-SSH הנפוץ במערכות linux. תחילה, "נכריח" את השרת להקשיב לכתובת ספציפית אחת ולא לכל הכתובות (שכנראה) מוגדרות במערכת. כמובן, נחסום גישת root ישירה כיוון שאנו רוצים שכל משתמש יתחבר דרך חשבונו בלבד (ואם הם צריכים גישת root לפעולות מסוימות – נגדיר su עבורם.
בנוסף, נבטל את האפשרות לאימות ע"י סיסמה – כלומר, הדרך היחידה להתחבר לשרת תהיה ע"פ האימות התקני של פרוטוקול ה-SSH (הווה אומר – מפתחות ציבוריים).
לפרנואידים ממש – נשנה גם את פורט הגישה לפרוטוקול.
שינוי הגדרות שרת ה-SSH מתבצע ע"י עריכת קובץ ההגדרה: /etc/ssh/sshd_config :

# Package generated configuration file # See the sshd(8) manpage for details # What ports, IPs and protocols we listen for Port 2289 #שינוי הפורט # Use these options to restrict which interfaces/protocols sshd will bind to #ListenAddress :: #ListenAddress 0.0.0.0 ListenAddress 192.168.2.10 #הגדרת כתובת ספציפית אחת Protocol 2 # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key #הגדרת מפתחות ציבוריים של קליינטים HostKey /etc/ssh/ssh_host_dsa_key #Privilege Separation is turned on for security UsePrivilegeSeparation yes # Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 768 # Logging SyslogFacility AUTH LogLevel INFO # Authentication: LoginGraceTime 120 #PermitRootLogin yes PermitRootLogin no #ביטול התחברות ישירה של חשבון מנהל StrictModes yes RSAAuthentication yes PubkeyAuthentication yes #AuthorizedKeysFile     %h/.ssh/authorized_keys # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 HostbasedAuthentication no # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication #IgnoreUserKnownHosts yes # To enable empty passwords, change to yes (NOT RECOMMENDED) PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no # Change to no to disable tunnelled clear text passwords #PasswordAuthentication yes PasswordAuthentication no # Kerberos options #KerberosAuthentication no #KerberosGetAFSToken no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes # Deactivate port forwarding AllowTcpForwarding no #X11Forwarding yes X11Forwarding no X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes #UseLogin no #MaxStartups 10:30:60 #Banner /etc/issue.net Banner /etc/issue # Allow client to pass locale environment variables AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server UsePAM yes

הגדרת SUDO
SUDO הינו יישום המעניק גמישות בבקרת הגישה המצויה במערכות לינוקס. היישום "מחליף" את מודל ה-root or nothing ומעניקה למנהל המערכת אפשרות להקצות הרשאת root לפקודות מסוימות במערכת ללא הצורך בסיסמת ה-root. קובץ ההגדרות של SUDO נמצא ב-/etc/sudoers אבל עריכתו חייבת להיעשות באמצעות פקודת ה-visudo.
גישה מלאה
הפעולה הבאה מעניקה הרשאה מלאה – קרי root למשתמש maor, לכן שימו לב למי אתם מעניקים גישה שכזו.

root@maor-debian# visudo # /etc/sudoers # User privilege specification root ALL=(ALL) ALL maor ALL=(ALL) PASSWD: ALL #זו השורה שהוספנו

גישה לפקודה מסוימת
נניח כי המשתמש yosi צריך הרשאה ע"מ להריץ את tcpdump. בואו ניתן לו גישה:

root@maor-debian# visudo # /etc/sudoers # User privilege specification root ALL=(ALL) ALL yosi ALL=(ALL) PASSWD: /usr/sbin/tcpdump -ni eth0 #זו השורה שהוספנו

ביטול אתחול המערכת באמצעות צירוף המקשים CTRL+ALT+DEL
מערכות לינוקס רבות "מקבלות" אות (syscall) לאתחול המערכת עת צירוף המקשים Ctrl+Alt+Del – כן, כמו במערכות MS-DOS. כדי למנוע הפתעות לא נעימות, בואו נחסום אפשרות זו;
תחילה, יש לערוך את /etc/inittab ולשנות את השורות הבאות:

# What to do when CTRL-ALT-DEL is pressed. #ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now #נוסיף את השורה הבאה במקום זאת שמעל ca:12345:ctrlaltdel:/usr/bin/logger -s -p auth.notice -t [INIT] "CTRL+ALT+DEL caught but ignored! This is not a Windows(r) machine."

ע"מ להחל את ההגדרות, נריץ את הפקודה: init q .

עדכון המערכ(ו)ת באופן אוטומטי
אוקי, נתקלתי בהרבה מנהלי מערכות שביקשו להקל על עבודתם (ועל עומס אחריותם) בהקשר של עדכון חבילות המערכת. ובכן, אני לא ממליץ על עדכון אוטומטי לחלוטין (update + upgrade) מהסיבה הפשוטה שקיימים עדכונים הדורשים קלט ממנהל המערכת. חרף זאת, נוכל לבצע אוטומטיזציה על החלקים המשעממים.
אז ככה: נחליט כי כל בוקר, בשעה 05:30, המערכת תלקט את העדכונים הקיימים (apt-get update) , תבדוק אילו מהם באמת נדרשים למערכת (apt-show-versions –u) – ותשלח אלייך דוח לתיבת המייל. מה שנשאר לך – מנהל המערכת לעשות הוא לקרוא את המייל, לברור אילו מהעדכונים נחוצים ולבצע את העדכון (apt-get upgrade) בהתאם למדיניות החברה או הארגון .
תחילה, נוסיף את השורה הבאה (כחשבון root) ל-crontab:

root@maor-debian# crontab -e #### Update the APT database every morning (apt-get update) #### 30 5 * * * apt-get update > /dev/null 2>&1

ניצור סקריפט שיתחבר ב-SSH למערכת (שוב, ללא סיסמא אלא ע"י מפתח ציבורי) שיבדוק אילו עדכונים נחוצים למערכת:

#!/bin/bash # # update_check.sh # # Look for servers needing updates. We trust that apt-get update has already been done. # # When                 Who                What # 2015-08-31        Maor                Original version # MAORSERVER="maor-debian maor-debian2" for MAORSERVER in ${MAORSERVER} do echo ===Available updates for ${MAORSERVER}=== ssh ${MAORSERVER} apt-show-versions -u 2> /dev/null done

ושוב, נוסיף פעולה ל-crontab שתריץ את הסקריפט ותשלח אלייך את הדוח:

#### Checking for available updates #### 0 7 * * * /bin/bash /home/sysop/update_check.sh | /usr/bin/mail -s "Linux Updates Available on (`/bin/date -R`)" maor@domain.com

כיף, נכון?

לסיום, כאמור – מערכות לינוקס הינן מודולריות – הן מורכבות מהרבה יישומים המרכיבים את הפונקציונליות שלה. חשבו על מינימליזם, כמה שפחות שירותים – ככה ייטב. בנוסף, הקפידו לתעד את המערכת. תמיד. הפעולות שהצגתי הן מנדטוריות ובסיסיות למערכות "ריקות", הווה אומר כי לכל שירות (למשל apache) יש פעולות הקשחה נפרדות. אשתדל לכתוב פוסט להקשחה יותר מעמיקה לשירותים נוספים (חשבו defense-in-depth) – אבל עד אז... זכרו כי להבדיל מחלונות, לינוקס רק נותנת לכם את האפשרות ש-"זה לא יקרה".
 

על הערכת (ניתוח) סיכונים

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

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

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

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

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

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

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

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

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

תרשים זרימת תהליך ההכנה להערכת סיכונים ע"פ NIST

ביצוע הערכת הסיכונים – שתי הגישות

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

הערכת סיכונים מבוססת איכות

הערכות (או ניתוח) סיכונים איכותיות – מפיקות תוצאות המבוססות על תיאורים כנגד מידה.

ביצוע הערכה בגישה זו רווחת כאשר:

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

חשוב לציין כי בעת ביצוע הערכה בגישה זו – יש לקחת בחשבון את הדברים הבאים:

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

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

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

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

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

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

הערכת סיכונים מבוססת כמות

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

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

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

אבל מהו מחיר הנזק? איך מעריכים הפסד כזה או אחר? ובכן, קיימת "נוסחה"; יש תחילה לחשב את ה-"צפי להפסד בודד" (SLE). ה-SLE (Single Loss Expectancy) ע"פ הגדרה, מוגדר כהפרש בין הערך המקורי לערך הנוצר לאחר מימוש האיום או החולשה. ביתר קלות, אפשר לחשב את ה-SLE ע"פ הקשר הבא:

כאשר ה-Exposure factor הינו נמדד באחוזים ומהווה את פוטנציאל ההפסד לנכס מסוים.

ה-Asset value, כשמו הוא – מעיד על ערך הנכס (בד"כ בדולרים).

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

לאחר חישוב ה-SLE, העסק או הארגון ירצו לחשב את ה-"הסתברות השנתית למאורע", או ARO. ה-ARO (Annualized Rate of Occurrence) הינה הערכה של תדירות מימוש מוצלח של איום או חולשה.

לבסוף, העסק ירצה לחשב את ה-"צפי להפסד בשנה", או ALE. ה-ALE (Annualized Loss Expectancy) מחושב כמכפלת ה-ARO ב-SLE.

בהינתן ה-SLE, העסק או הארגון יוכל לקבוע את תקציב אמצעי ההגנה לנכסיו. חשוב לציין – אותו תקציב לא יהיה יקר יותר מהערך עליו מגנים (קרי הנכס).

מתודולוגיות הערכת סיכונים

NIST SP 800-3x series

באופן אישי, מתודולוגיות הערכת הסיכונים של NIST הינן החביבות עליי. מתודולוגיות אלו הן מסוג הערכות סיכון איכותיות (Qualitative). הן פותחו ע"י מכון התקנים האמריקאי לשימוש הממשל האמריקאי בפרט ולציבור העולם בכלל. כיום, נעשה בהן שימוש נרחב בסקטורים מפוקחים (רגולטורים) כגון הסקטור הבריאותי והפיננסי. מתודולוגיה נפוצה הינה 800-30 המכוונת לניהול סיכונים במערכות מידע. 800-39 מכוונת לניהול סיכונים ארגוני.

FRAP

ה-FRAP או The Facilitated Risk Analysis Process, הינה מתודולוגיה העושה שימוש בהנחה ש-"הערכת סיכונים באופן המצומצם ביותר – הינה היעילה ביותר". היא מכוונת למערכות, תוכנות, תהליכים וסקטורים עסקיים. ע"פ מתודולוגיה זו, הערכת הסיכון שמה לה למטרה מספר בודד של סובייקטים (מערכות, תהליכים וכו') ומתמקדת בסובייקטים "שבאמת" צריכים את אותו ניתוח סיכונים. התהליך עצמו דורש תקציב דל ויכול להיעשות ע"י כל יועץ או בעל כישורים ניהוליים.

מטריצת סיכונים ע"פ גישת FRAP. התמונה באדיבות pivotpointconsulting.com

SOMAP

ה-SOMAP או The Security Officers Management and Analysis Project הינו ארגון שוויצרי ללא מטרות רווח ומבורך אשר שם לו למטרה ניהול ותחזוקה של אבטחת מידע בעזרת כלים ותיעודיות חינמיים מבוססי רישיון GNU. הארגון יצר מעין חוברת הנחיות וכלים העוזרים להבין את מהות והפרקטיקה של ניהול הסיכונים. בחוברת שלהם, מוצגות שתי השיטות לביצוע הערכת סיכון (כמותית ואיכותית) ומסבירה את חשיבות בחירת המתודולוגיה בהתאם למטרות הארגון. הכלים, החוברת והמדריכים הינם זמינים באתר שלהם: http://www.somap.org .

תהליך הערכת סיכונים ע"פ SOMAP

CRAMM

"הסוכנות הבריטית למחשבים ולטלקומוניקציה" פיתחה שיטה לסקירת היבטי אבטחת מידע במשרדי ממשלתה. ה-CRAMM או CCTA Risk Analysis and Management Method הינה מתודולוגיה תלת-שלבית ששימשה לקביעת תאימות (הסמכה) לתקן BS7799 (התקן הבריטי לניהול מערכות אבטחת מידע – שלימים היווה בסיס לתקן הבינלאומי ISO 27001). כאמור, המתודולוגיה מורכבת מ-3 שלבים ונעזרת בשאלונים והנחיות ע"מ לכסות היבטי אבטחה בפן הטכני (מערכות IT, תוכנות וכו') ובפן הלא-טכני (עובדים, גישות פיזיות וכו'). שלוש השלבים הינם:

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

חישוב רמת\דרגת הסיכון

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

ובאופן טיפה יותר פורמלי – בהינתן מערך של i∈ℕ | i > 0 סיכונים, I השפעה (המבוטאת כנזק או הפסד כספי) וההסתברות כפונקציה של אותה ההשפעה – חישוב הסיכון יהיה:

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

הסתברות (או היתכנות) (L)	השפעה (רמת הנזק\ההפסד הכספי) (I)
(1) גבוהה ביותר	(100) הרת אסון – נזק המונע פעילות עסקית לטווח ארוך
(0.5) בינונית - לעתים	(50) גבוהה – נזק הגורר הפסד כספי מעל X ₪
(0.1) נמוכה – היתכנות "נדירה"	(10) נמוכה – נזק הגורר הפסד כספי שלא עולה על Y ₪

כיוון שעסקינן ב-3 רמות של היתכנות והשפעה, המטריצה תהיה ריבועית ובגודל 3×3 .