چرا اسکن پورت هنگام اجرا با 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 راه‌حل ناسازگاری سیاست نیست؛ راه‌حل بیان سیاست موردنظر از طریق مالک سرویس است.