למה סריקת פורטים משתנה כשמריצים אותה עם sudo

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

שתי בדיקות, פורט אחד, מסלולי קוד שונים

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

המסלול הגולמי דורש CAP_NET_RAW, ולכן הסריקה המוגדרת כברירת מחדל נחלשת בשקט כשהיכולת הזו חסרה. מדריך טכניקות הסריקה של Nmap עצמו מתעד את ההחלפה: סריקת connect היא הגיבוי כי היא אינה דורשת הרשאות מיוחדות כלל. ההחלפה קורית בלי אזהרה ברוב ההרצות, וזה מה שהופך אותה לכל כך קלה לקריאה שגויה. ברגע שיודעים שהגיבוי קיים, “פתוח כ-root, סגור כמשתמש” מפסיק להישמע כמו באג הרשאות ומתחיל להישמע כמו שתי מדידות שונות.

מה sudo באמת משנה בסריקה

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

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

שמרו על השיטה קבועה בשתי ההרצות

כפו את אותה טכניקה בשתי הקריאות וההשוואה מתחילה לומר משהו. הדגל -sT מבקש סריקת connect במפורש, -Pn מסיר גילוי מארחים, -n מסיר פתרון שמות, ו־-p יחיד מסיר הבדלים ברשימת הפורטים.

nmap -sT -Pn -n -p 8443 198.51.100.77
sudo nmap -sT -Pn -n -p 8443 198.51.100.77

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

הקשר החשבון אינו רק דגל הרשאה

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

בדקו את המדיניות ולא את ההרשאה. ב-Linux, nftables מבטאת זאת עם meta skuid ו-iptables עם התאמת הבעלים, וכל אחת מהן יכולה לשלוח UID יחיד דרך מנהרה בעוד השנייה ממשיכה להשתמש במסלול הפיזי המוגדר כברירת מחדל.

sudo nft list ruleset | grep -n skuid
sudo iptables-save | grep -n uid-owner
ip rule show
ip route get 198.51.100.77

אמתו את הבדיקה לפני השוואת תוצאות

לפני הסקת מסקנות, הוכיחו איזו בדיקה רצה. Nmap נותן שם לטכניקה בפלט שלו, ו־--reason מוסיף את הראיה מאחורי כל מצב, וזה החלק שאומר לכם אם לחיצת יד באמת הושלמה.

nmap --reason -sT -Pn -n -p 8443 198.51.100.77
sudo nmap --reason -sS -Pn -n -p 8443 198.51.100.77
getcap "$(command -v nmap)"
capsh --print | grep -i net_raw

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