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

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

גישה לאינטרנט

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

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

• תכנית
• הגדרות BGP
• הגנת DOS/DDOS
• סינון תנועה בחומת האש

תכנית

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

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

הערה:

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

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

• נתבי גבול
• חומות אש

הערה 1

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

הערה 2

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

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

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

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

דוגמא 1. העיכוב

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

דוגמא 2. פרודוקטיביות

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

דוגמא 3. אמינות

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

אז, נניח שהשירות שלך מתקיים על גבי http/https (עם הפעלות קצרות). במקרה זה, ניתן להשתמש בשתי תיבות עצמאיות (ללא HA) ואם יש בעיית ניתוב באחת מהן, להעביר את כל התעבורה לשניה.

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

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

חשוב!

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

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

דוגמה

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

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

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

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

אבל מה לגבי ההגנה במקרה זה?

בואו נסתכל, למשל, על הפופולרי לאחרונה התקפת DNS Amplification DDOS. הסכנה שלו טמונה בעובדה שנוצרת כמות גדולה של תנועה, שפשוט "סותמת" 100% מכל ה-uplinks שלך.

מה יש לנו במקרה של העיצוב שלנו.

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

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

הגדרת BGP

יש כאן שני נושאים.

• קישוריות
• הגדרת BGP

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

דוגמא 1

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

דוגמא 2

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

דוגמא 3

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

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

משאבים שימושיים:

ripe.net
bgp.he.net

דוגמה

אני אתן רק דוגמה אחת קטנה.

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

בוא נניח שאתה מספק שירות מסוים, ויש לך מספר מספיק של לקוחות מאוקראינה, והם מתלוננים על עיכובים ארוכים. במהלך המחקר שלך, גילית שכתובות ה-IP של חלק מהן נמצאות ברשת 37.52.0.0/21.

על ידי הפעלת traceroute, ראית שהתנועה עוברת דרך AS1299 (Telia), ועל ידי הפעלת ping, קיבלת RTT ממוצע של 70 - 80 מילישניות. אתה יכול לראות את זה גם ב מראה זכוכית Rostelecom.

באמצעות כלי השירות whois (ב-ripe.net או כלי שירות מקומי), אתה יכול בקלות לקבוע שבלוק 37.52.0.0/21 שייך ל-AS6849 (Ukrtelecom).

לאחר מכן, על ידי מעבר ל bgp.he.net אתה רואה שאין ל-AS6849 קשר עם AS12389 (הם לא לקוחות ולא קישורים מעלה זה לזה, וגם אין להם הצצה). אבל אם מסתכלים על רשימת עמיתים עבור AS6849, תראה, למשל, AS29226 (Mastertel) ו-AS31133 (Megafon).

ברגע שתמצא את המראה של ספקים אלה, אתה יכול להשוות את הנתיב וה-RTT. לדוגמה, עבור Mastertel RTT יהיה כ-30 מילישניות.

לכן, אם ההבדל בין 80 ל-30 אלפיות השנייה משמעותי עבור השירות שלך, אז אולי אתה צריך לחשוב על קישוריות, לקבל את מספר ה-AS שלך, את מאגר הכתובות שלך מ-RIPE ולחבר קישורים למעלה ו/או ליצור נקודות נוכחות ב-IXs.

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

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

הגנת DOS/DDOS

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

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

כאן אתה יכול למצוא קישורים אליהם.

אהובי המפה מ-CheckPoint.

ההגנה מפני DDOS/DOS היא בדרך כלל שכבתית. כדי להבין מדוע, עליך להבין אילו סוגי התקפות DOS/DDOS קיימים (ראה, למשל, כאן או כאן)

כלומר, יש לנו שלושה סוגים של התקפות:

• התקפות נפח
• התקפות פרוטוקול
• התקפות יישומים

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

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

דוגמה

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

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

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

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

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

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

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

דוגמא 1

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

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

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

דוגמא 2

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

נניח שכתוצאה מבעיה קצרת טווח עם אחד מהספקים הראשיים שלך, מחצית מהמפגשים שלך נבוכים. אם האפליקציה שלך מעוצבת בצורה כזו שבלי לחשוב פעמיים, היא מיד (או לאחר מרווח זמן זהה לכל הפגישות) מנסה ליצור מחדש את החיבור, אז תקבלי לפחות 50 אלף מנות SYN בקירוב בּוֹ זְמַנִית.

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

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

הרמה השלישית של הגנה מפני DDOS/DOS היא הגדרות חומת האש שלך.

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

המועצה

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

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

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

סינון תעבורה על חומת האש

בואו נמשיך את השיחה על חומת האש. אתה צריך להבין שהתקפות DOS/DDOS הן רק סוג אחד של התקפות סייבר.

בנוסף להגנת DOS/DDOS, אנו יכולים לקבל גם משהו כמו רשימת התכונות הבאה:

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

זה תלוי בך להחליט מה אתה צריך מתוך רשימה זו.

המשך יבוא

מקור: www.habr.com