-->

יום שני, 24 באוקטובר 2016

התקפת מניעת-שירות, וכיצד האינטרנט בחוף המזרחי - הושבת?

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

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


סצנה מתוך סרט "הציפורים" של היצ'קוק. מקור: http://www.filminamerica.com/Movies/TheBirds

כיצד נראית התקפת DoS?


להלן דוגמה פשוטה מאוד:

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

Refresh Monkey. הטאב יבצע refresh חמש פעמים בשנייה - ואני יכול גם לפתוח מאה טאבים כאלו.

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

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


--

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

הדף הראשי של האתר - הוא דף שמתוכנן להיות מהיר. רוב ה traffic מגיע אליו. העבודה שנעשית בו היא שליפה של חתולים באזור נתון. בחולון, העיר בה אני גר יש כמות ממוצעת של חתולים שמוזנים במערכת, אולם אם אדווח על המיקום שלי במרכז ת"א - צפיפות החתולים המתועדים גדולה פי שלושה!
בכדי לשפר את ההתקפה שלי - עלי לחשוב כיצד אני גורם לשרת לעבוד יותר קשה. אם אוכל לגרום לדף הראשי באתר לעבוד קשה יותר, אולי כך אפגע ביותר משתמשים, נניח 15% מהמשתמשים.


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


מצאתי באתר דף שנקרא: ״פריסה ארצית של חתולים ויחס האכלות״. בינגו! זה כנראה דף שלמערכת הרבה יותר קשה לרנדר (כי הרינדור מבוסס על חיתוכים וסיכומים בבסיס הנתונים). אם הנתונים אינם cached בצורה יעילה (מה שיכול ממש לקלקל!) - אני מסודר.
כמו כן, סביר יותר שדף שולי במערכת זכה לפחות שיפורי ביצועים - פשוט כי התנועה הדלילה אליו פחות משפיעה על סה"כ ביצועי המערכת.
עבורי  - זו הזדמנות מצויינת! אני אלמד את בוני האתר כמה לא יעיל הקוד מאחורי הדף הזה (!Muahaha). אני משגר עשרות בקשות בשנייה לרינדור הדף, ומייד מנתק את ה connection (ללא RST - מבלי להודיע). לשרת ייקח כמה שניות להבין שנעלמתי - ובזמן הזה הוא עדיין יעבוד להכין את הדף ולנסות לשלוח אותו אלי.

התקפה כזו עשויה להיות הצלחה גדולה: אמנם ״פריסה ארצית של חתולים ויחס האכלות״ - הוא דף שאינו חשוב במערכת, אבל אותם CPU ו Database שמשרתים אותו - משרתים גם את שאר המערכת. ברגע שתפסתי אותם, הצלחתי למנוע שירות מ90% מהמשתמשים הלגיטימיים שמנסים לגשת לאתר הבית, ולהאט משמעותית את זמני התגובה ל 10% המשתמשים שכן הצליחו לקבל שירות. הצלחה גדולה!


מקור: Scudlayer



על DDoS ו SDoS


לאחר שהבנו כיצד התקפת DoS עובדת - מה בעצם המשמעות של DDoS, מונח שהוא כנראה אפילו יותר מוכר?

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

יתרה מכך, מנגנוני ההגנה המקובלים בפני התקפת DoS היא לזהות כמות לא סבירה של traffic ממשתמש יחיד - ואז לחסום אותו ברמה היעילה ביותר (למשל: לדחות בקשות ל tcp connection, הנדרש בכדי לבצע בקשת HTTP, על בסיס כתובת IP של השולח).

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




על מנת לייצר התקפת DDoS יעילה, עלי לאסוף אלפי מחשבים, אולי עשרות אלפים, ואולי יותר - שאולי לשלוט בהם. כל מחשב כזה נקרא Zombie, וצבא של זומבים נקרא גם BotNet. האיסוף מתבצע בד"כ ע"י נוזקה שתתוקן במחשב ותהיה במצב רדום - עד אשר ארצה לבצע את ההתקפה. הנוזקה לא צריכה "להשתלט על המחשב": היא רק צריכה להתקין agent שמאזין ל port מסוים ומאזין לפקודות משרת ההפעלה שלי. בעת ההתקפה, בעל המחשב כנראה לא ירגיש בכלל שהוא שותף להתקפה. לא יפריע לו - ולא יהיה לו טריגר לנסות ולהסיר את ה agent שלי.
את הנוזקה אני יכול להפיץ באתרי הורדות קבצים במשך חודשים או שנים - עד לרגע ההפעלה. מי שרוצה לקצר תהליכים ויש ברשותו משאבים - יכול גם לרכוש רשתות BOTNET בשוק העברייני, ממישהו שטרח והקים אותן.

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

ההתקפה על Dyn. מקור: TechCrunch

מה שהיה חדש יחסית בהתקפה הוא השימוש ב "מכשירים בסיסיים" או "דברים" (IoT - Internet Of Things) - לביצוע ההתקפה. כלומר: הזומבים ב Mirai Botnet הם טוסטרים, שואבי אבק, מצלמות אבטחה - רכיבים שונים בעלי גישה לאינטרנט. הנוזקה "Mirai" סורקת את האינטרנט וברגע שמזהה מכשיר שכזה מנסה להתחבר אליו כ Admin בעזרת רשימה של users/passwords נפוצים שיש ברשותה. אלו הם לרוב ה defaults שמסופקים מהיצרן או שם וססמה קבועים - שלא ניתן בכלל להחליף.

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

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


בעוד על DDoS כולם כבר שמעו, על SDoS כמעט ולא שומעים - אין גאווה גדולה לארגון לספר שהותקף בכזו התקפה.

SDoS הם ראשי תיבות של Self Denial of Serive (מושג מקביל: Unintended Denial of Service) בהם ארגון מייצר לעצמו traffic שהוא לא מסוגל לעמוד בו - ואז נאלץ לדחות (= לא לספק שירות), לכמות גדולה של משתמשים לגיטימיים.

דוגמה קלאסית: קמפיין שיווקי שלא תואם (או אולי תואם, ותוצאותיו לא נצפו ע"י ה R&D/Operations) - שמגדיל את התעבורה פי כמה מונים - אך המערכת לא יכולה לעמוד בכמות ה traffic שנוצר.

פאדיחות.


בהתקפת DoS/DDoS זה מה שאתם רוצים שבעלי האתר יראו: פחות traffic מטופל, וזה שמטופל - הוא איטי ומציק.
מקור התמונה: New Relic


סגנונות תקיפה נפוצים


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


בכל זאת, ניתן לאפיין ברמה הטכנולוגית כמה סגנונות נפוצים לביצוע התקפות DoS/DDoS:


HTTP Flood

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

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

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

טריק פשוט ומקובל הוא לייצר אלמנט אקראי (למשל: ב query string) ב URL - שיגרום ל CDN לחשוב שאין לו את המשאב - ולהעביר את הבקשה ישירות לאתר.
למשל:

https://feed_a_cat.co.il/comprehensive-cats-report?random=198982

הרכיב "random=198982" ב URL כמעט ואף פעם לא יגרום לשרת לדחות את הבקשה (מי מתגונן בצורה כ"כ הדוקה?) - ובד"כ יגרום ל CDN לחשוב שמדובר במשאב ייחודי שלא נמצא אצלו ב Cache.



התקפות רזות: SYN Flood ו UDP-Based

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

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

הרעיון של התקפות אלו הוא להימנע מיצירת ה TCP connection, שהיצירה שלו אורכת זמן (גוזלת מהמתקיף משאבים) - ואז יש יעד ברור לתשובה.
להזכיר: TCP Connection הוא הבסיס לביצוע HTTP Request. לא יהיו לנו בקשות HTTP בסגנון ההתקפה הזה.

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

אולי אפילו טוב יותר: הוא לא יענה במשך זמן ממושך (או בכלל) - ואז המערכת אותה תקפנו לא תוכל בכל הזמן הזה לשחרר את המשאבים שהקצתה לצורך ה connection. רוב המערכות יחכו כמה שניות ואז יוותרו על המאמץ לייצר connection, מערכת שלא עושה זאת (אין לה timeout) - היא פשוט טרף קל!

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

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

אפשר לבצע Ping / Echo ולתת לשרת לענות. אפשר לנסות Pings עם payload גדול - שעשויים להקשות על השרת המרוחק, ואפשר (זה ממש מרושע) לנסות לשקר שכתובת ה IP שלנו היא כתובת של שרת אחר ב cluster של המערכת המותקפת - ואז לתת לשרתים השונים של המערכת לבצע ping בינם לבין עצמם...

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



התקפות Amplification (הגברה)

אם יש בשליטתי 10,000 זומבים, ואני יכול לחבר לכל אחד מהם "מגבר" שיאפשר לו לייצר פי 10 traffic - הרי שכללתי במידה רבה את כלי ההתקפה שלי!

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

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

מגברים "טבעיים" אחרים שניתן למצוא ברשת האינטרנט כוללים:
  • שרתים שעונים לפרוטוקול SNMP (פרוטוקול ניהול רשת) - היחס בין גודל הבקשה לגודל התשובה יכול להגיע לעד פי 600, יותר! לרוע המזל, אין הרבה שירותי SNMP שפתוחים לאינטרנט הרחב...
  • שירותי NTP (כלומר: Network Time Protocol, הפרוטוקול בעזרתו שרתים מסתנכרנים על השעה הנכונה) - הם יעד פופולארי. פקודת monlist של הפרוטוקול (המחזירה רשימה של 600 השרתים האחרונים שביקשו שירות) היא בעלת יחס החזרה של פי 200.
  • מערכות Peer to Peer - שניתן למצוא פרצה ולבלבל את כל ה Peer שאנו מתקשרים איתם באותו הרגע ולחשוב שהשרת המותקף הוא בעצם אני. הם עלולים לנסות שוב ושוב עד שיקבלו את התשובה שהם מצפים לה...
  • וכו'

התקפות הגברה נמדדות לרוב בכמות ה Bandwidth שהן מייצרות. השיאים נשברים כל הזמן, והשיא הידוע לי הוא 602 Gbps - כלומר: traffic של 602 ג'יגהביט בשנייה (או 75 ג'יגהבייט בשנייה). שיא שבוודאי יישבר.





סיכום


מה הופך התקפות DDoS לכ"כ פופולאריות?
  • הן פשוטות יחסית ליישום. הרבה יותר פשוטות מהתקפות אחרות. 
  • הן מתאימות כמעט לכל מטרה: הן לא תלויות ב stack טכנולוגי מסוים, או בפגיעויות מסוימות של המערכת.
  • קשה לאתר את התוקף - ובמיוחד בהתקפות שאינן מבוססות על TCP. היכולת להתחמק - היא אינטרס עליון של התוקף.

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

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


כיצד מתגוננים?
  • מעבירים את התעבורה לאתר דרך שירות שיודע לזהות ולסנן traffic של התקפת DDoS (כמו CloudFlare או Akamai) . שירות כזה עולה כסף, אך הוא מסוגל לאתר ולמנוע מכם את רוב ה traffic של התקפת DDoS. 
  • חוסמים לגישה מהאינטרנט כל port או endpoint שאינו הכרחי.
  • בונים את המערכת כך שיהיה ניתן להשבית (disable) בקלות מנגנונים יקרים במשאבים של המערכת. בעת התקפה, עדיף לאבד יכולת או שתיים של המערכת - מאשר את כל המערכת.


שיהיה בהצלחה!




9 תגובות:

  1. היי פוסט ממש מעניין. אשמח לשמוע מה זה שירות WAF ואיך הוא פותר את הבעיה.

    השבמחק
    תשובות
    1. היי אלון,

      WAF (קיצור של Web Application Firewall) הוא כמו Firewall ש"מבין" תעבורה של HTTP. הוא יודע לזהות (ולסנן, במידת הצורך) הודעות בפורמט שגוי או לא סביר של פורמט HTTP, יכול לסרוק את ה payload של הבקשה (בפני SQL Injection, למשל), או לאכוף חוקים ברמת ה HTTP שמי שמכיר את האפליקציה - יכול להגדיר, ע"פ ההיכרות עם המערכת כיצד היא אמורה לעבוד (וכיצד לא).

      לא דייקתי כשציינתי הפתרון הנדרש כפתרון WAF.
      CloudFlare ו Akamai (וגם אינקפסולה הישראלית) הן רשתות CDN שהקימו גם הגנה בפני התקפות DDoS. מערך ההגנה הזה מורכב מ WAFs, אבל גם Firewalls - הרי חלק מההתקפות של DDoS מתרחשות ברמות 3 ו 4, כלומר: UDP, TCP, ICMP, וכו'. יש גם עניין של rate limits, שאולי הם עושים בעזרת חומרה ייעודית (?).

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

      ברגע שאתה רוכש שירות הגנה שכזה, אתה מעביר את כל ה traffic שלך דרכם (ע"י רישום ב DNSs) - והם מסננים אותו ומזהים בעצמם התקפות DDoS פוטנציאליות. באופן זה הם יכולים גם להשליך מלקוחות אחרים שלהם שמותקפים - תובנות נוספות לגבי הההתקפה. מכיוון שבכדי לקבל שירות CDN (קיצור של Content Delivery Network) נהוג כבר להעביר את התעבורה דרך ספק ה CDN - יש סינרגיה גדולה בספק שגם מספק שירותי CDN וגם שירותי הגנה בפני DDoS.

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

      מקווה שהצלחתי להבהיר את הדברים,
      ליאור

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

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

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

    רק הסיום של הפוסט קצת פרווה לטעמי:
    האם שירות סינון, חסימת גישות בלי נחוצות, ויכולת השבתה יזומה של חלקים מהמערכת - אלו כל הפתרונות ששווה להציג?
    מה עם, למשל, להעסיק איש אבטחת מידע שיהיה אמון על ניתוח והגדרת אמצעים להתגוננות (או לפחות: זו תהיה "הבעיה שלו" ;-) ) (או לפנות לייעוץ חיצוני)
    מה עם שלל האמצעים המוזכרים פה:
    https://en.wikipedia.org/wiki/Denial-of-service_attack#Application_front_end_hardware
    מן הסתם יש יותר עומק להתגוננות משניתן לסכם בשלושה bulletים.
    ואולי אני סתם מתקטנן.

    השבמחק
    תשובות
    1. תודה על ההערה!
      ייתכן ויש עוד דברים משמעותיים שניתן לעשות - אני לא מכיר.

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

      מחק
  3. יצא לי להשתמש ב incapsula שזה שירות די טוב,
    אך אני רוצה לציין את cloudfront של AWS, שמוכר לנו בתור CDN
    אבל אפשר גם לחבר אליו origin שהוא לא S3 אלה ממש האתר שלהם, ויש שם הגנת DDOS מובנית,
    עם שלל אפשרויות, ובמחיר שכל אחד יכול לחבר לבלוג שלו.

    שוב פוסט מצויין, והסבר רהוט. תודה!


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

    השבמחק