چگونه ترافیک سوءاستفاده‌ای را که از یک خروجی VPN می‌آید گزارش کنیم
گزارش سوءاستفاده از یک خروجی VPN: توقف ترافیک را از شناسایی یک شخص جدا کنید، کانالی را انتخاب کنید که می‌تواند اقدام کند و شواهد محدود بفرستید.
ترافیک یک خروجی VPN می‌تواند سوءاستفاده‌آمیز باشد بی‌آنکه بگوید چه کسی آن را فرستاده است، و گزارشی که می‌نویسید به این بستگی دارد که به کدام‌یک از سه پرسش پاسخ می‌دهید. متوقف کردن ترافیک امروز کار خود شماست. حفظ شواهد یک رویه است. شناسایی یک شخص به فرایند حقوقی نیاز دارد که احتمالاً ندارید. گزارش‌ها وقتی شکست می‌خورند که این سه در یک شکایت آمیخته شوند، زیرا گیرنده فقط می‌تواند روی بخشی که مالک آن است اقدام کند.
نخست سه پرسش را از هم جدا کنید
با تصمیم درباره نتیجه‌ای که می‌خواهید آغاز کنید. اگر هدف متوقف کردن درخواست‌هاست، امروز می‌توانید محدوده نشانی را مسدود کنید، نرخ حساب را محدود کنید یا نقطه پایانی را سخت‌تر کنید، و گزارش سوءاستفاده ثانویه است. اگر هدف سندی است که از بازبینی سالم بیرون می‌آید، به مهرهای زمانی، شناسه‌های درخواست و نسخه اصل ویرایش‌نشده‌ای نیاز دارید که جای امنی نگهداری شود. اگر هدف نامی پشت نشانی است، به فرایند حقوقی اپراتور یا حکم دادگاه نیاز دارید، و هیچ شکایت خصوصی جای آن را نمی‌گیرد.
آمیختن آن‌ها گزارش کلاسیک بی‌فایده را می‌سازد: یک بند خشمگین، بدون منطقه زمانی، درخواست جزئیات مشترک و هیچ اشاره‌ای به اینکه گیرنده حتی اگر بخواهد کمک کند چه می‌تواند بکند. چنین گزارشی بدون اقدام بسته می‌شود و فرستنده نتیجه می‌گیرد که میزهای سوءاستفاده کاری نمی‌کنند. گیرنده چیزی برای اقدام نداشت.
پیش از باز کردن ایمیل، سه پاسخ را بنویسید. آن‌ها لحن، طول و درخواست را تعیین می‌کنند.
نشانی خروجی چه چیزی را ثابت می‌کند و چه چیزی را نه
نشانی مرتبط با VPN به شما می‌گوید ترافیک از کجا وارد اینترنت شده است، نه اینکه چه کسی آن را آغاز کرده است. خروجی تجاری همزمان میان بسیاری از مشتریان مشترک است و NAT در سطح اپراتور در جلوی آن می‌تواند یک نشانی عمومی را با استفاده از محدوده پورت میان هزاران مشترک تقسیم کند. RFC 6269 آن مدل اشتراک نشانی را توصیف می‌کند و پیامد عملی آن این است که نشانی مبدأ به‌همراه مهر زمانی تنها زمانی می‌توانند مشترکی را شناسایی کنند که اپراتور هنوز نگاشت آن لحظه را داشته باشد.
آنچه را می‌توانید اثبات کنید ثبت کنید. این یعنی مهر زمانی به وقت UTC با یادداشت منطقه اصلی، نشانی مبدأ، پورت مبدأ، پروتکل و شناسه درخواست، و اینکه اقدام از یک حساب احرازشده آمده یا از یک درخواست ناشناس. سابقه خام را نگه دارید، سپس نسخه‌ای ویرایش‌شده برای گیرنده بسازید. تصویر صفحه جایگزین ضعیفی برای خط اصلی در گزارش است.
بازه‌های نگهداری کوتاه‌اند و از اپراتوری به اپراتور دیگر متفاوت. هر چه زودتر بپرسید، احتمال وجود نگاشت بیشتر است، و این استدلال اصلی برای گزارش سریع است حتی وقتی مشکل را قبلاً کاهش داده‌اید.
کانالی را انتخاب کنید که واقعاً می‌تواند اقدام کند
سه کانال وجود دارد و جایگزین یکدیگر نیستند. میز سوءاستفاده اپراتور خروجی می‌تواند مشتری خودش را بررسی کند و شاید حساب را تعلیق کند. تماس ثبت‌شده محدوده نشانی می‌تواند وقتی سابقه whois کهنه است یا به یک فروشنده مجدد تعلق دارد شما را به اپراتور درست راهنمایی کند. اجرای قانون به جرم مشکوک، تهدید و نفوذ جدی می‌پردازد و تنها این کانال می‌تواند در بیشتر حوزه‌های قضایی افشا را الزامی کند.
| Channel | What it can do | What it cannot do |
|---|---|---|
| Exit operator abuse desk | Investigate, warn or suspend the account | Disclose a subscriber to a private complainant |
| Registry contact | Identify the network holder and its abuse address | Act on the incident itself |
| Law enforcement | Preserve and compel records under legal process | Move faster than your own mitigation |
دو شرط کانال را انتخاب می‌کنند. آیا حادثه در جریان است، که به کاهش در ابتدا و گزارش موازی اشاره دارد، یا تاریخی است، که به حفظ شواهد پیش از هر چیز اشاره دارد؟ آیا به توقف ترافیک نیاز دارید، که هر سه می‌توانند بر آن اثر بگذارند، یا به هویت نیاز دارید، که تنها مسیر حقوقی می‌تواند فراهم کند؟ شرط سومی تعیین می‌کند چه مقدار جزئیات بفرستید: اپراتوری که خروجی را اداره می‌کند به مشخصات فنی نیاز دارد، در حالی که تماس ثبت‌شده فقط به محدوده نشانی و مشکل نیاز دارد.
وقتی حادثه جرمی در جریان است، میز سوءاستفاده و مقامات جایگزین نیستند. به هر دو گزارش دهید و به اپراتور بگویید که ممکن است درخواست حقوقی دنبال شود تا سیاست نگهداری خودش فعال شود.
گزارشی بنویسید که گیرنده بتواند بر آن اقدام کند
پیام را به‌اندازه‌ای کوتاه نگه دارید که در یک دقیقه خوانده شود. یک بند می‌گوید چه شد و کِی، یک بلوک شواهد را با مهرهای زمانی دقیق فهرست می‌کند، یک خط می‌گوید چه کرده‌اید و یک خط می‌گوید چه می‌خواهید. درخواست شماره ارجاع پرونده را در پایان بگذارید تا تحلیلگر شلوغ با یک شماره پاسخ دهد نه با یک گفت‌وگو.
اسرار را از نسخه‌ای که می‌فرستید حذف کنید. گذرواژه‌ها، توکن‌های نشست، داده‌های شخصی نامرتبط و نام میزبان‌های داخلی به گیرنده کمک نمی‌کند و مواجهه خودتان را بالا می‌برد. نسخه اصل ویرایش‌نشده را در جایی با دسترسی محدود و هش ثبت‌شده نگه دارید اگر حادثه ممکن است شاهد حقوقی شود. دستورهای زیر پیش از نوشتن هر چیز، واقعیت‌های عمومی درباره یک نشانی را جمع می‌کنند.
whois 198.51.100.7 | grep -iE 'orgname|netrange|abuse'
dig +short -x 198.51.100.7
grep '198.51.100.7' /var/log/nginx/access.log | head -n 20نشانی‌ای را که واقعاً مشاهده کرده‌اید جایگزین کنید و توجه کنید که محدوده مستندسازی مانند مورد بالا سابقه زنده برنمی‌گرداند. اگر خروجی whois به‌جای برند VPN یک ارائه‌دهنده میزبانی را نام ببرد، همان ارائه‌دهنده گیرنده درست است، زیرا تخصیص نشانی و رابطه مشتری را در اختیار دارد.
پاسخ را مدیریت کنید و سابقه را نگه دارید
سکوت به معنای رخ ندادن چیزی نیست. اپراتورها معمولاً بر پایه یک گزارش اقدام می‌کنند بی‌آنکه به گزارش‌دهنده بگویند، هم چون نمی‌توانند اطلاعات مشتری را افشا کنند و هم چون سیاستشان ممکن است آن را ممنوع کند. تأیید کوتاه با شماره پرونده بیشترین چیزی است که باید انتظار داشته باشید، و درخواست جزئیات فنی بیشتر نشانه خوبی است نه تأخیر.
تا زمانی که گزارشی باز است، اتهامی علیه یک نشانی یا ارائه‌دهنده منتشر نکنید. نامیدن یک خروجی مشترک به‌عنوان مقصر، هر مشتری دیگر آن خروجی را مجازات می‌کند و اگر بعداً به فرایند حقوقی برسد می‌تواند به پرونده آسیب بزند. راهنمای واکنش به حادثه NIST منشأ و محرمانگی سوابق حادثه را بخشی از واکنش می‌داند، نه کاغذبازی پس از آن.
حلقه را در سوابق خودتان ببندید: چه فرستادید، به چه کسی، کِی، و در نتیجه چه تغییری کرد. همان تاریخچه است که حادثه بعدی را از آشفتگی به رویه‌ای با نخستین گام شناخته‌شده تبدیل می‌کند.