בואו נספור את הסוכנים "מפקח"

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

מותקן ישירות אצל הספק מודול "מפקח סוכן":

מודול "מפקח סוכן" הוא מרכיב מבני של המערכת האוטומטית "מפקח" (AS "מפקח"). מערכת זו נועדה לפקח על תאימות של מפעילי טלקום לדרישות הגבלת גישה במסגרת ההוראות שנקבעו בסעיפים 15.1-15.4 של החוק הפדרלי מיום 27 ביולי 2006 מס' 149-FZ "על מידע, טכנולוגיות מידע והגנת מידע. ”

המטרה העיקרית של יצירת AS "Revizor" היא להבטיח מעקב אחר תאימות של מפעילי טלקום לדרישות שנקבעו בסעיפים 15.1-15.4 של החוק הפדרלי מ-27 ביולי 2006 מס' 149-FZ "על מידע, טכנולוגיות מידע והגנת מידע "במונחים של זיהוי עובדות של גישה למידע אסור וקבלת חומרים תומכים (נתונים) על הפרות להגבלת גישה למידע אסור.

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

לפני שנספור, בואו נראה למה זה בכלל אפשרי.

קצת תיאוריה

סוכנים בודקים את הזמינות של משאב, כולל באמצעות בקשות HTTP(S), כגון זו:

TCP, 14678  >  80, "[SYN] Seq=0"
TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

HTTP, "GET /somepage HTTP/1.1"
TCP, 80  >  14678, "[ACK] Seq=1 Ack=71"
HTTP, "HTTP/1.1 302 Found"

TCP, 14678  >  80, "[FIN, ACK] Seq=71 Ack=479"
TCP, 80  >  14678, "[FIN, ACK] Seq=479 Ack=72"
TCP, 14678  >  80, "[ACK] Seq=72 Ack=480"

בנוסף למטען, הבקשה מורכבת גם משלב יצירת חיבור: החלפה SYN и SYN-ACK, ושלבי השלמת החיבור: FIN-ACK.

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

לשם כך, עליך לבחור דומיין חינמי מתאים עם סוג חסימת "URL" ו-HTTP כדי להקל על עבודת מערכת הסינון, רצוי שננטשה מזמן, כדי למזער את כניסת תעבורה חיצונית למעט סוכנים. משימה זו התבררה כלא קשה; ישנם לא מעט דומיינים חינמיים במרשם המידע האסור ולכל טעם. לכן, הדומיין נרכש וקישר לכתובות IP ב-VPS פועל tcpdump והספירה התחילה.

ביקורת של "מבקרים"

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

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

סטייה לירית קטנה. קצת יותר מיום לאחר מכן, ספק האירוח שלי שלח מכתב עם תוכן די יעיל, ואמר שהמתקנים שלך מכילים משאב מרשימת האסורים של RKN, ולכן הוא חסום. בהתחלה חשבתי שהחשבון שלי חסום, זה לא המקרה. ואז חשבתי שהם פשוט מזהירים אותי על משהו שכבר ידעתי עליו. אבל התברר שהמארח הפעיל את הפילטר שלו מול הדומיין שלי וכתוצאה מכך עברתי סינון כפול: מהספקים ומהמארח. המסנן עבר רק את קצות הבקשות: FIN-ACK и RST ניתוק כל HTTP בכתובת URL אסורה. כפי שניתן לראות מהגרף שלמעלה, לאחר היום הראשון התחלתי לקבל פחות נתונים, אך עדיין קיבלתי אותם, מה שהספיק למדי למשימת ספירת מקורות הבקשות.

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

מכיוון שהמטרה הראשונית שלי לא הייתה בדיוק, ספרתי את כל הכתובות שנתקלתי בהן תוך שבוע וקיבלתי - 2791. מספר מפגשי TCP שנקבעו מכתובת אחת הוא בממוצע 4, עם חציון של 2. מפגשים מובילים לכל כתובת: 464, 231, 149, 83, 77. המקסימום מ-95% מהמדגם הוא 8 מפגשים לכל כתובת. החציון אינו גבוה במיוחד, הרשו לי להזכיר לכם שהגרף מראה מחזוריות יומית ברורה, כך שניתן לצפות למשהו בסביבות 4 עד 8 תוך 7 ימים. אם נזרוק את כל הפגישות שמתרחשות פעם אחת, נקבל חציון השווה ל-5. אבל לא יכולתי לכלול אותם על סמך קריטריון ברור. להיפך, בדיקה אקראית העלתה שהן קשורות לבקשות למשאב אסור.

כתובות הן כתובות, אבל באינטרנט, מערכות אוטונומיות - AS, שהתבררו כחשובות יותר 1510, בממוצע 2 כתובות לכל AS עם חציון של 1. כתובות מובילות לכל AS: 288, 77, 66, 39, 27. המקסימום של 95% מהמדגם הוא 4 כתובות לכל AS. כאן צפוי החציון - סוכן אחד לכל ספק. אנחנו מצפים גם לטופ - יש בו שחקנים גדולים. ברשת גדולה, סוכנים צריכים כנראה להיות ממוקמים בכל אזור של נוכחות המפעיל, ואל תשכח את NAT. אם ניקח את זה לפי מדינה, המקסימום יהיה: 1409 - RU, 42 - UA, 23 - CZ, 36 מאזורים אחרים, לא RIPE NCC. בקשות מחוץ לרוסיה מושכות תשומת לב. זה כנראה יכול להיות מוסבר על ידי שגיאות מיקום גיאוגרפי או שגיאות רשם בעת מילוי נתונים. או העובדה שלחברה רוסית אולי אין שורשים רוסיים, או שיש לה נציגות זרה כי זה קל יותר, וזה טבעי כשמתעסקים עם ארגון זר RIPE NCC. חלק מסוים הוא ללא ספק מיותר, אבל קשה להפריד אותו באופן אמין, מכיוון שהמשאב נמצא תחת חסימה, ומהיום השני תחת חסימה כפולה, ורוב הפעלות הן רק החלפה של מספר מנות שירות. בואו נסכים שזה חלק קטן.

ניתן כבר להשוות מספרים אלו למספר הספקים ברוסיה. לפי RKN רישיונות ל"שירותי תקשורת להעברת נתונים, למעט קול" - 6387, אך מדובר בהערכה גבוהה מאוד מלמעלה, לא כל הרישיונות הללו חלים ספציפית על ספקי אינטרנט שצריכים להתקין סוכן. באזור RIPE NCC יש מספר דומה של ASes רשומים ברוסיה - 6230, שלא כולם ספקים. UserSide עשה חישוב קפדני יותר וקיבלה 3940 חברות ב-2017, וזו דווקא הערכה מלמעלה. בכל מקרה, יש לנו פי שניים וחצי פחות מספר ASs מוארים. אבל כאן כדאי להבין ש-AS אינו שווה למהדרין לספק. לחלק מהספקים אין AS משלהם, לחלק יש יותר מאחד. אם נניח שלכולם עדיין יש סוכנים, אז מישהו מסנן חזק יותר מאחרים, כך שלא ניתן להבחין בין הבקשות שלו לאשפה, אם הם מגיעים אליהם בכלל. אבל להערכה גסה זה די נסבל, גם אם משהו אבד בגלל ההשגחה שלי.

לגבי DPI

למרות העובדה שספק האירוח שלי הפעיל את הפילטר שלו מהיום השני, על סמך המידע מהיום הראשון נוכל להסיק שהחסימה עובדת בהצלחה. רק 4 מקורות הצליחו לעבור והשלימו לחלוטין הפעלות HTTP ו-TCP (כמו בדוגמה למעלה). ניתן לשלוח עוד 460 GET, אך הפגישה מופסקת מיד על ידי RST. שים לב ל TTL:

TTL 50, TCP, 14678  >  80, "[SYN] Seq=0"
TTL 64, TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TTL 50, TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

HTTP, "GET /filteredpage HTTP/1.1"
TTL 64, TCP, 80  >  14678, "[ACK] Seq=1 Ack=294"

#Вот это прислал фильтр
TTL 53, TCP, 14678  >  80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678  >  80, "[RST] Seq=3458729893"

HTTP, "HTTP/1.1 302 Found"

#А это попытка исходного узла получить потерю
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[ACK] Seq=294 Ack=145"

TTL 50, TCP, 14678  >  80, "[FIN, ACK] Seq=294 Ack=145"
TTL 64, TCP, 80  >  14678, "[FIN, ACK] Seq=171 Ack=295"

TTL 50, TCP Dup ACK 14678 > 80 "[ACK] Seq=295 Ack=145"

#Исходный узел понимает что сессия разрушена
TTL 50, TCP, 14678  >  80, "[RST] Seq=294"
TTL 50, TCP, 14678  >  80, "[RST] Seq=295"

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

אתה אפילו לא יכול לראות את זה מהשאר GET:

TTL 50, TCP, 14678  >  80, "[SYN] Seq=0"
TTL 64, TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"

#Вот это прислал фильтр
TTL 53, TCP, 14678  >  80, "[RST] Seq=1"

או כך:

TTL 50, TCP, 14678  >  80, "[SYN] Seq=0"
TTL 64, TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TTL 50, TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

#Вот это прислал фильтр
TTL 53, TCP, 14678  >  80, "[RST, PSH] Seq=1"

TTL 50, TCP ACKed unseen segment, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"

#Опять фильтр, много раз
TTL 53, TCP, 14678  >  80, "[RST, PSH] Seq=1"
...

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

TCP, 14678  >  80, "[SYN] Seq=0"
TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TCP Retransmission, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
...

או כך:

TCP, 14678  >  80, "[SYN] Seq=0"
TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

#Прошло несколько секунд без трафика

TCP, 80  >  14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...

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

לגבי IPv6

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

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

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

לסיכום

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

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

ממש לא ציפיתי שהמארח יכלול גם פילטר משלו עבור ה-VPS שלי. אולי זה נוהג מקובל. בסופו של דבר, RKN שולח בקשה למחיקת המשאב למארח. אבל זה לא הפתיע אותי ובמובנים מסוימים אפילו פעל לטובתי. המסנן עבד ביעילות רבה, קטע את כל בקשות ה-HTTP הנכונות לכתובת אתר אסורה, אך לא נכונות שעברו בעבר דרך המסנן של הספקים הגיעו אליהן, אם כי רק בצורה של סיומות: FIN-ACK и RST - מינוס למינוס וכמעט התברר שזה פלוס. אגב, IPv6 לא סונן על ידי המארח. כמובן שזה השפיע על איכות החומר שנאסף, אבל זה עדיין איפשר לראות את התדירות. התברר שזו נקודה חשובה בבחירת אתר להצבת משאבים, אל תשכחו להתעניין בנושא ארגון העבודה עם רשימת האתרים האסורים ובקשות מהרק"ן.

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

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

מקור: www.habr.com